The popular open source framework to easily add in-app settings to your iPhone apps has been released in version 3.0. Normally, iOS apps use the Settings.bundle resource to add app-specific settings in the Settings app. InAppSettingsKit takes advantage of the same bundle and allows you to present the same settings screen within your app. So the user has the choice where to change the settings.
But InAppSettingsKit goes one step further. It not only replicates the system settings feature set but supports a large number of additional elements and configuration options if the settings screen is displayed within the app. Many developers even remove the settings pane from the system settings and solely rely on a rich in-app settings screen.
InAppSettingsKit 3.0 comes with the following new features:
List Groups (great for a variable number of items such as tags or accounts)
Date Picker
Toggles with checkmarks (instead of switches)
Text field validation
Support hiding sections
Support of the iOS text content type (allows auto-filling the name, email address and more)
Even though InAppSettingsKit is written in Objective-C, it plays nicely with Swift. In 3.0, I added nullability annotations and using properties instead of getter methods to improve the Swift interoperability. In fact, I rewrote the sample app in Swift to show this.
TL;DR
For many form-like table view UIs, InAppSettingsKit is a great choice because it saves a ton of error-prone code. Simply configure the UI using a static plist and only add a few lines of code for interactivity such as dynamic section hiding or input field validation.
Check the GitHub page for all the details and if you like the framework, you can now sponsor my open source work to support the future development of the framework. ?
Recently, I was wondering why Where To? on iPhone X didn’t show the activity indicator in the status bar while it was fetching places from the network. I discovered that iPhone X actually doesn’t display the system network activity indicator. Apple writes in the Human Interface Guidelines:
On devices without edge-to-edge displays, a network activity indicator spins in the status bar at the top of the screen as networking occurs.
So the iPhone X, iPhone XS and XR simply don’t show the network activity indicator at all. While I consider this a bug and submitted a Radar (? UIActivityIndicatorView should be shown on iPhone X) for it, I needed a solution.
I remembered that in an early beta of the iPhone X Simulator, I saw a K.I.T.T. scanner-style indicator with a linear gradient that was placed above or below the status bar items:
So I decided to implement this kind of indicator. It’s placed in the right “ear”, above the status bar icons. It’s convenient to use by simply “fixing” the existing network activity indicator on iPhone X/XS/XR. So apps using the network activity indicator continue to work as usual but also display the indicator on iPhone models with a notch. In addition, it can also be used as a standalone indicator view and tinted with a custom color.
The indicator is available as open source on GitHub and as a CocoaPod. Feel free to use it in your own apps!
The next Where To? update will of course use this as well to fix the missing activity indicator on iPhone X.
After our launch of Where To? 10 which includes an iMessage app, I was fascinated how it would perform in the new iMessage App Store. Similar to the Apple Watch App Store, Apple chose to build a new, separate App Store for iMessage apps.
The US store differs from other stores in that it has categories (similar to the iOS App Store but with fewer categories) and Top Charts. I didn’t check many other countries but it looks like the US is unique in this regard.
Update Sept 16: Top charts and categories seem to roll out worldwide. At least in Germany and Italy, they’re now available, albeit with fewer categories.
Top Charts are interesting because they offer an insight how the market works and which categories and business models are most successful.
I went through the list of 150 apps in both the Top Free and Top Revenue charts and made an analysis on the type of content and the business models used. Some items were hard to categorize because there are apps that are essentially just sticker packs. Or there are iOS games that have a sticker pack attached. I tried to categorize them according to their actual content.
First, sticker packs drastically outnumber apps and games. The revenue share generated by sticker packs is even higher than the free download share of sticker packs. So clearly, users have no problem whatsoever to open their purse for well-designed pixels.
The relatively small number of games was surprising to me. Apparently, only a small percentage of games benefits from iMessage integration, specifically turn-based games.
The distribution of business models is even more interesting. In contrast to the iOS App Store where freemium titles dominate the top-grossing charts, the overwhelming revenue in the iMessage App Store comes from paid titles. This reminds me of the early days of the App Store where In App Purchase wasn’t even available.
Probably the #1 reason for this is the lack of IAP in no-code sticker packs. These sticker packs consist only of the actual artwork and are easy to create for designers who don’t want to code.
Nevertheless, even the three of four games in the grossing charts are traditionally paid and 9 of the 12 apps.
Another observation I made: the sales and the ranking of iOS apps including an iMessage app seem to be independent in both stores. For instance, at the time of writing these lines, Where To? ranked #73 in the (overall) US iMessage Top Revenue charts but didn’t rank at all in the US iOS App Store, even on the category level.
US iMessage App Store added top lists. Where To? scored #73, or #11 when excluding Sticker apps. Excited & thankful! pic.twitter.com/JZpleXmHIF
We’re only at day one of the iMessage App Store so it’s hard to predict what the future will hold but I expect (and kind of hope, as an app developer) the number of apps and games in the top charts to increase. Stickers are new and fresh and everyone wants to try them but after the initial excitement levels down and after users have already filled one screen with sticker packs, users will probably gravitate towards deeper apps and games that promise longer lasting benefit. Another reason for this is development time. Developers only had three months of time since Apple introduced the first beta of iOS 10 at WWDC16 – actually less because of bugs in early betas. Developing a great app or game takes time so we’ll definitely see more non-sticker titles in the future.
I also believe the ratio of freemium titles will increase vs. paid-upfront titles, even for sticker packs. It’s not hard to see that there will be tools to automatically generate sticker pack apps with only a few free stickers and the rest of them locked behind an IAP wall. As soon as designers have the (easy) choice, they’ll make use of it.
Overall, it’s fascinating to follow the launch of this new economy with its own new laws of physics and I’m really curious to watch this fourth baby (after the iOS, Mac and Apple Watch App Stores) grow over time. For us, it’s an exciting business opportunity and I’m glad we’re part of it since day 0!
9% of all current Where To? users also have an Apple Watch and ran Where To? for Apple Watch at least once. That’s what our backend statistics show. We’re surprised by this high number just 3 months after the Apple Watch launch!
If we put this in relation to the 350 million iPhones sold since 20141 that would result in an astonishing 31 million Apple Watches sold!
Of course I know this comparison is flawed in a number of ways 2 so the share of Apple Watch owners amongst Where To? users is certainly much larger than in the overall market. Nevertheless, the number is fascinating and encouraging!
If you have an Apple Watch and haven’t yet tried out Where To?, I encourage you to do so, too. And we’ll be closer to 10% soon! đ
I recently came across a private API to find out the hardware device color of iPhone, iPad and iPod touch. There are two color values, the DeviceColor (front side) and the DeviceEnclosureColor (bezel/back side). The latter is not supplied in all cases. Here’s the code to retrieve these values:
With this knowledge at hand I decided to write a small demo app that displays the artwork and the device colors and lets you share them. Unfortunately, this uses a private API, so don’t use this in App Store builds as your app will get rejected!
Nevertheless I can imagine various interesting use cases to match the interface UI with the hardware color. So if you’d like to see this in a public API, feel free to dupe my radar.
Our FileMaker database where we import rankings and featured entries for each day and country
News from our little tool to monitor the App Store for featured entries: Thanks to Dominik Wagner from TheCodingMonkeys, the script to scrape App Store Featuring entries gained a noticeable speed bump. Using multi threading it now completes in 16 seconds, down from 36 seconds!
The script detects the following featured entries and prints them in one line per country:
Home page: mentioned somewhere on the root level homepage, including the Top 10 rankings
New and Noteworthy page: This is more or less identical to the home page. Depending on the country, the extra page may contain some more apps.
What’s Hot page
Any other page linked the same way (with selection box on the homepage)
Category page: mentioned somewhere on the category page, including the Top 10 rankings
Category “New”
Category “What’s Hot”
How to call the script
To start the script you just need the iTunes ID of the app, the category and “iPhone” or “iPad” depending on which store you want to check:
./iTunesFeatured.pl 314785156 Navigation iPhone
09.08.2011 AE App Store: Home page, Staff Favourites Navigation: Home pâŠ
09.08.2011 AR App Store: Home page, Staff Favourites Navigation: Home pâŠ
09.08.2011 AT App Store: TOP STAGE, Home page Navigation: Home page
The output is structured as a tab-delimited text with columns for date, country, root level mentions and category mentions. This makes it easy to import the output into a spreadsheet, database or anything else.
iPhone developers using Core Location in their apps sometimes have a hard time. To test their apps, they have to go outside and conduct real-world tests. Not the worst thing fitness-wise, at least if you’re using a bike-mount holder, but rather inconvenient if you wanna attach your iPhone to your laptop running Xcode.
The iPhone simulator so far was not a big help because it only sends location updates from your Mac using Wi-Fi positioning. To test apps like Where To? which update POIs while moving, it’s not a practical solution.
That’s the reason we wrote our own Core Location simulator and presented it for the first time at the Macoun 2010 conference in Frankfurt. FTLocationSimulator delivers fake location updates to the application. The Core Location part is pretty straight-forward, we basically replicate the CLLocationManager API. The MapKit integration for the blue UserLocation dot is a bit harder: Apparently, Core Location talks directly to MapKit to update the position of the UserLocation dot. So we had to reach into our bag of tricks:
First, we determine the userLocation view and then we update their screen coordinates manually. As a side benefit, we nicely animate it as you can see in the video.
The waypoints for the location updates are taken from a KML file, in this case a route from Cupertino to San Francisco. You can use your own KML file by generating it with Google Earth (our KML “parser” is very basic and it’s not guaranteed to work with any KML file). If you watch the video closely, you’ll notice that the speed of the location updates varies. This is due to varying distances between waypoints on curvy or straight parts of the road. We currently don’t consider the distance between waypoints.
Integration of the code is easy and described in the Readme. At the moment, we don’t support advanced Core Location features such as speed, course, altitude, distance filtering and region monitoring. Also, our faked version of the UserLocation dot doesn’t have the nice halo GPS locating animation.
Nevertheless, we hope the code is useful for developers using Core Location in their apps. If you’re having feedback or wanna contribute to the project, we’re to glad to hear from you in the comments or on GitHub.
Update 04.02.2011: Deutsche Leser finden in der aktuellen Mac Developer 2/2011 unter dem Titel âFreie Fahrt am Schreibtischâ einen Beitrag zu FTLocationSimulator und seiner Einbindung in iPhone-Apps.
Most of them came to the conclusion that the patent itself wouldnât steal any of Where To?âs design or functionality. Nilay Patel over at Engadget explains:
The only operative parts of a patent are the claims. (âŠ) If it’s not in the claims, it’s not in the patent.
Indeed, when looking through the claims 1-21, thereâs no evidence of anything close to Where To?âs functionality. Our patent attorney confirmed this. The claims of this patent application are actually pretty narrow with the core invention being a method that detects the arrival of a traveler based on the itinerary and the fact that the device was turned off and turned back on again, and then sending out some sort of arrival notification.
The confusion arose from Appleâs including a 1:1 copy of the Where To? start screen in the detailed description (which basically sets the context of the invention).
Anand Sethuraman, Senior Patent Counsel at Apple, came back to our enquiry and explains in an email:
As discussed, Apple is contemplating steps to attribute the screenshot in the patent application to FutureTap. The patent application in question does not claim as inventive the pictured user interface nor the general concept of an integrated travel services application. Â We appreciate your taking time out to discuss the matter and will keep you updated.
So the use of the Where To? screenshot is not an offense in any way but merely an illustration that apps such as Where To? could make use of the invention. We feel honored over this mention and appreciate that Apple is looking into a proper attribution of the screenshot. In retrospective, I can say we wouldnât ever have considered the story alarming had the screenshot included a short attribution notice.
Looking back, Iâm thankful for the great support of the community. We received a lot of good advice and many readers sympathized. Only the Apple haters who chimed in with their âApple is evilâ attitude have been proven wrong now. I also read a few aggressive (mostly anonymous) feedback comments that called to boycott us because of our inability in understanding patent law. It’s true, we had no clue of patent law, the US one in particular. We learned a lot the last few days. Yet, my response to those boycotteurs:
Do you prefer developers who love reading patents over the ones who love to design user interfaces?
Nevertheless, I truly apologize if we stepped on anyoneâs feet. And now, letâs go back to work.
Now some folks argued we might have a deal in place with Apple. I can assure you: we don’t. The story was equally surprising for us as for many others.
At first, we couldn’t believe what we saw and felt it can’t be true that someone else is filing a patent including a 1:1 copy of our start screen. Things would be way easier of course if that “someone else” would be really an exterior “someone else”. Unfortunately, that’s not the case.
We’re faced with a situation where we’ve to fear that our primary business partner is trying to “steal” our idea and design. So how to deal with that? â As some of you know, we’ve always been more than grateful for the platform Apple created. And, in fact, still are. However, we can’t ignore it if the #1 recognition value of our (currently) only app potentially is under fire.
Where To? 1.0 with its characteristic home screen has been launched on day 1 of the App Store. The patent has been filed in December 2009. And clearly, the number of details with all the icons, their ordering and the actual app name “Where To?” in the title bar (which, as a sidenote, doesn’t make a lot of sense as a module in a potential iTravel app) can’t be randomly invented the same way by someone else.
I’m not a lawyer. I can’t really judge whether the inclusion of a 1:1 copy of our start screen in someone else’s patent is legal. I just have to say, it doesn’t feel right. (If you can recommend a good, affordable patent lawyer, please let us know.) The perspective of an endless legal battle, however, is not very intriguing for a small company like us that aims to throw all its power into improving existing and developing new apps. So we definitely hope there’ll be an easy solution. Perhaps it’s just a flaw in the filing that can be fixed easily. If someone from Apple Legal reads these lines, you’re welcome to discuss.
In summary, this episode once more reinforces my personal aversion against software patents. In my opinion they discriminate against smaller developers who can’t afford building a huge legal department to defend against such patent cases and to research existing patent mine fields.
What do you think about the case? Are we overreacting? Please let us know in the comments, we’re glad to hear your thoughts.
Update 6.8.2010 15:44 CEST: Reading some of the comments, we’d of course love to jump to the conclusion that the Where To? drawing is just meant as an example of related apps. Even if that’s the case, we’d have expected, though, to be informed directly and in advance and not after the fact via the press. Brian Ford nails it:
The real problem, as I see it, is that no one thought to approach FutureTap, and let them know that theyâd be doing so. I deal with patent applications a lot at work because theyâre often used as evidence in trials that I work on, and thereâs no way around the fact that theyâre hard to decipher. Bloggers are bound to read a lot into this, and a lot of the speculation is going to be based on a lack of information.
However, we’re not completely convinced, the filing uses Where To? just as an example and we should be glad for the free marketing. First of all, I question the marketing power of 20+ page patent filings. Second, we actually read the patent application. The relevant part of the patent application reads like this:
[0056]In some embodiments, a user can view available airport services through the integrated application. As used herein, the term “airport services” can refer to any airport amenities and services such as shops, restaurants, ATM’s, lounges, shoe-shiners, information desks, and any other suitable airport services. Accordingly, through the integrated application, airport services can be searched for, browsed, viewed, and otherwise listed or presented to the user. For example, an interface such as interface 602 [602 refers to the Where To? drawing depicted above, note by the author of these lines] can be provided on a user’s electronic device. Through interface 602, a user can search for and view information on the various airport services available in the airport. In some embodiments, airport services can be prioritized based on their location in the airport (e.g., using an integrated or associated mapping application). For example, the available services can be filtered such that airport services within a certain distance of a user’s gate are displayed (e.g., within 1000 feet of the user’s gate, or within any other suitable distance). In some embodiments, a map of the airport can be provided that indicates the available airport services.
This paragraph sounds like it describes Where To?’s functionality pretty exactly. I admit though, I found no evidence in the important claims part (1.-21. at the very beginning of the patent application). Again, I’m not a lawyer (but I learned this awesome abbreviation: IANAL :-)). Since all this is pure speculation, I guess our best advice is to stay calm and see what the lawyers say. After all, we should take legal advice from non-lawyers with a pinch of caution.
Also, we do hope that we’ll get a response to the inquiries we sent to Apple. (Actually, one of the reasons we waited nearly a week with this post, was to give Apple time to respond. When we were bombarded with rfc’s yesterday, we had to come out of the hiding, though.) So before we jump to false conclusions, we should give Apple a fair chance to explain.
Update 11.8.2010: Meanwhile, Apple responded and the whole case is resolved amicably.
Should iPhone app settings be placed in Settings.app or included in-app? â There has been quite some debate on that topic and we don’t want to repeat everything all over again.
In our eyes there are a lot of good reasons to take the in-app route:
Settings.app becomes a total mess with more and more apps and takes long to load all apps
Most users simply don’t understand the mechanism and miss the settings if they are only placed in Settings.app
A context switch is needed to switch between settings and the app. If the app happens to be on the 16th screen, this involves quite some tapping and flicking.
In-App settings can instantly change the behavior of the app
On the other hand, some (albeit a minority, we feel) users are used to the mechanism of Settings.app. Also, being part of Settings.app gains some user exposure and apps included there are viewed as first-class citizens by many advanced users.
So how can this dilemma be solved?
Many apps decide to get rid of a Settings.app pane altogether. Interestingly, all user-installable apps from Apple are amongst them (Remote, Keynote Remote, MobileMe iDisk). Further examples are Twitterrific, AIM and countless others.
We’re proposing a second approach that we call “hybrid settings”. In this model, the user has the choice: the settings are available in Settings.app. But they’re placed in-app as well. That way, every user can decide where to edit the settings. The in-app settings are a 100% clone of the Settings.app style.
How does it look like?
Well, the settings look exactly the same as in Settings.app. This consistency does make sense if we don’t want to confuse our users. In TouchPad, a “Settings” button shifts in the settings dialog. In Where To?, the settings are entered by tapping on the i-icon on the top right of the first screen. The settings then appear with a nice flip animation known from Weather.app or Stocks.app. Alternatively, a navigation push or a tab bar can be used.
Can I integrate this in my app?
At first, the solution was developed by Luc Vandal of Edovia and Ortwin Gentz of FutureTap because we both had the need. So we wrote this piece of software as a Canadian-German co-production. Then, we thought twice and felt the code might be useful for some other folks. So we decided to release InAppSettingsKit as open source. We hope it will be adopted widely.
iPhone developers using Core Location in their apps sometimes have a hard time. To test their apps, they have to go outside and conduct real-world tests. Not the worst thing fitness-wise, at least if you’re using a bike-mount holder, but rather inconvenient if you wanna attach your iPhone to your laptop running Xcode.
We’re proposing a second approach that we call “hybrid settings”. In this model, the user has the choice: the settings are available in Settings.app. But they’re placed in-app as well. That way, every user can decide where to edit the settings. The in-app settings are a 100% clone of the Settings.app style.