My stance on the Apple/Epic drama: Epic deliberately broke App Store rules every developer has to follow. Why have they done that? It looks foolish to intentionally break the rules just to launch a huge campaign when faced with the foreseeable consequences.
However, they’re certainly not dumb and lose $25,000 per hour for fun. It was a well orchestrated campaign instrumenting their user base in a PR fight against Apple and suing them at the same time. They wanted to get kicked out of the App Store in order to portray themselves as the David fighting against the Goliath and have a reason to file an already prepared lawsuit. They try to compel Apple to a better deal. Certainly their timing is good since Apple is under increased scrutiny with the current App Store antitrust investigations.
As an indie dev I certainly welcome any reduction in Apple’s fees. While I do appreciate what an amazing platform Apple has created with the App Store in the last dozen years and while I do think Apple should make fair money running it, their 30% cut is no longer appropriate in my opinion.
So Epic fighting the 30% cut should be more than welcome for us indie devs? Not so fast. I’m not sure this will be the outcome of this Epic/Apple tug of war. Epic is a multi billion business and their interest is most likely not aligned with us indies. So while I hope for change, I hope there will be change that everyone benefits from, not only the big guys. Epic wants to legitimize their payment infrastructure outside of the App Store. That’s certainly not what most smaller developers want to build and operate.
Drew McCormack wrote an interesting proposal how a new App Store sales model could look like. I think it would be fair to let every commercial app pay their share for the cost of running the App Store, and not only tax App Store revenues. Currently, multi-billion dollar companies with ad-based business models pay nothing for the App Store platform while every purchase is taxed with 30%. By requesting a fair share from everyone based on download volume, the “sales tax” could be lowered substantially.
We should also not forget there are quite a few issues besides the sales model: unclear and overly broad rules, incoherent application of those rules, the lack of an independent ombudsman or panel to resolve disputes – to name just a few.
The best aspect of Epic (and others such as Facebook) picking a quarrel: There’s quite a momentum now to achieve meaningful change of the App Store. I’ll be watching closely how this will unfold.
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)
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.
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.
In Streets 4.5, we revised the Apple Watch app and introduced a true sphere viewer without distortion. You can now look around in all directions, not just horizontally. Either move your arm or just pan around using the finger to turn around or up and down in the panorama.
Tap the panorama once to select it (visualized with a green border) and zoom using the digital crown.
The update also includes the latest round of bug fixes.
The Where To? 10.9.3 update released today introduces support for Universal Links top open Where To? place links right within the app instead of the website. We also worked on the loading performance to make results appear more quickly. This is especially noticeable in categories such as post boxes, national parks, playgrounds and more. Then we improved the zooming behavior when results are initially loaded. In previous versions the map sometimes zoomed several times while loading the results. Now we zoom just once when all results are loaded.
In Where To? we put a lot of effort in respecting your privacy. This means, we never sell user location profiles – or even create them in the first place. So far, we still asked for “Always” location permission as soon as you wanted to create location alarms to notify you once you arrive at or leave from a certain place. In 10.9.3 we changed that functionality to use a newer API and thus no longer require “Always” location permission. As a consequence, we removed that permission from the app entirely and only ask for your location while the app is in use.
The update also supports sending your destination info to the “TwoGo” app, an interesting car pooling app. TwoGo allows to share or ask for a ride with users traveling in the same direction. In contrast to Uber, Lyft and the likes, TwoGo riders only pay a nominal fee to the driver covering gas and car wear and tear. The platform is financed by large companies encouraging their employees to share rides and thus saving valuable parking space. You can find more information on B2RIDE.
Streets 4.1 has landed on the App Store. The update improves support for Apple’s new devices such as the Apple Watch series 4, the iPhone XS, XS max, and XR as well as the new generation of iPad Pro with Face ID.
Streets now also supports Google’s Plus Code aka Open Location Code for easy location sharing. In the search field, you can enter a Plus Code to go to the location it specifies. And in the panorama share sheet, you can copy the Plus Code to the clipboard.
Grab the Streets 4.1 update from the App Store and if you’re in a good mood, treat us with a ⭐️⭐️⭐️⭐️⭐️ rating ❤️!
Where To? 10.9.1 is now available. It supports Spotlight search continuation: When you search for something using the system-wide search, there’s now an option to “Search in App” which continues the search right in the Where To? app.
Where To? 10.9.1 also includes a new round of bug fixes and improves the “Suggest an Edit” feature that now lets you specify the original listing when you report a duplicate. You can also propose additional categories where the listing should be found. So if you find some inaccuracies in Where To? listings, please let us know!