Swift Developments is a hand-curated newsletter containing a weekly selection of the best links, videos, tools and tutorials for people interested in designing and developing their own apps using Swift.
Here it is! Issue 73 of Swift Developments!
Before we dive in this week, I just wanted to make a quick correction for something I wrote in last weeks issue. As @timojaask, kindly pointed out, Bluepill, the new parallel testing framework from the team at LinkedIn, doesn’t yet support running Xcode’s UI testing bundle in parallel (as I implied). At present only the iOS Unit Testing bundle (including KIF and EarlyGrey Tests) is currently supported. Sorry, definitely a mistake on my part and I apologise if I caused any confusion!
Ok, now that we’re clear on that, let’s dive into this weeks links – There’s a lot to get through this week! Enjoy.
- A new beta SDK for iOS 10.3 was released this week.
- The new beta includes an
SKStoreReviewControllerclass that will allow you to prompt a users for an app reviews and have them complete that review all without leaving your app.
- There are limitations on the number of times you can prompt users however.
- These limitations are governed by Apple.
- Official documentation on the exact limitations is currently sparse.
- Various blogs hint at a limit of 3 notifications in any 365 day period.
- Prompts will not be displayed if a user has provided a review within that period.
- Users will also gain a switch in the settings app to disable all prompts for an app.
- Looks like theses will be the only sanctioned way of requesting reviews at some point in the future.
- In addition to the in-app review prompts, iOS 10.3 will also bring the ability for developers to respond to app reviews.
- Reviews / responses will be limited to a single review / single response though.
Although the App Store provides a great way for many developers to sell their apps, app reviews have been a contentious topic for some time. This week has seen the release of the first beta for iOS 10.3 and with it has comes some pretty big changes for the future of the App Store.
First up, the new SDK includes additional features that will allow developers to prompt users for reviews via a new
SKStoreReviewController class and an associated
Calling this method will trigger the display of a new built-in modal view that will prompt users for a review and allow them to submit a review without having to leave your app. There are a few caveats though.
According to the documentation, calling the
requestReview() method doesn’t actually guarantee that the review modal will be displayed. Instead this method is an indication to the App Store that it is a good time to display the review prompt within your app and it is Apple, not your code, then governs whether the modal is actually displayed.
“So when will this modal actually get displayed?” you may ask.
On this front, there seem to be a number of limitations that Apple will be building into the store but theres little detail in the official documentation. For some reason Apple have so far decided to communicate these limitations via third-party blogs such as daringfireball.net and loopinsight.com rather than via their own official developer documentation.
From what I can gather, the limitations will include not prompting users if they have already left a review, limiting review requests to a maximum of three per 365 days (regardless of whether you have a new release of your app or not) and also not prompting users if they have dismissed the review prompt three times. It also appears that users will be gaining the ability to permanently disable review requests on a per-app basis via the settings app.
The new APIs will eventually be the only sanctioned way for an iOS app to prompt for an App Store review, but Apple has no timeline for when they’ll start enforcing it. Existing apps won’t have to change their behavior or adopt these APIs right from the start.
From a bit more digging I also believe that in the mean time that Apple will be retaining the ability to deep link directly to the App Store product page.
Hand-in-hand with the SDK changes detailed above, Apple have also announced new capabilities for the App Store side of things as well.
Up until now, users have been able app leave reviews on the store but there has never been any way for developers to respond to those reviews. The release of iOS 10.3 is set to change this with Apple introducing the ability for developers to actually respond to reviews in the App Store! Finally!
From what I can determine these changes are going to be limited to a single review / single response though (no threaded conversations) but both customers and developers will be able to edit their review / response as many times as they like. Not as far as I would have liked it to go but a big step forwards.
Overall then some pretty big changes are coming to the store.
From my perspective I think these are a positive step forwards but I can’t help feeling the changes haven’t yet gone far enough and there are still far too many questions left unanswered at present.
Here are just a few that came to mind:
- I’m assuming the
requestReview()call will have no effect if the user is offline?
- What tools are Apple going provide to allow us to respond to users comments?
- Are they going to let us access the reviews from all the different stores in one place?
- What about responding to reviews left in other languages?
- Is there going to be some sort of automatic translation available?
- Are the users going to get notified when a developer leaves a response?
- What about contacting users directly? Are we going to have to respond with a ‘please email abc@xyz.’?
- What about unethical developers trying manipulate reviews?
- I’m assuming Apple will be doing something to catch developers trying to fake the review prompt, but what about more subtle forms of manipulation such as only displaying the review prompt to certain ‘good’ users? (I guess it’s arguable about whether this is ‘manipulation’ though).
- How much customisation are we going to get of the review prompts (say in terms of look and feel)?
- And the documentation… what about the documentation? (I’m not knocking the blogs who reported the limitations detailed above but seriously, Apple you really need to address this last one – releasing information via third-party blogs is NOT the way you should be providing developers with information).
I’m hoping the next few weeks will provide a lot more answers to the many questions that have surfaced in in recent days but in the longer-term, I’m going to be especially interested to see how these changes are going to change our interactions with our users. Definitely progress though.
So given the length of the item above, I bet you thought we were done with the iOS 10.3 beta but there’s actually another little surprise I thought I’d mention before we move on.
According to the documentation,
UIApplication seems to have gained three new methods with the release of this beta that will allow developers to change the icon for their app programmatically. It’s not quite the free-for-all that you might seem though as the users are going to have to confirm each and every icon change, a workflow I think is particularly jarring.
Now, I’m assuming Apple have implemented it this way to avoid apps quietly spoofing the icon of another app without the user knowing but I’m still a little mystified at the use case. I can definitely see need for certain app types (such as calendar apps) wanting to change the their app icons programatically but in it’s current implementation I’m not sure this is going to solve that problem. Whatever Apple’s reasoning though, @stroughtonsmith has knocked together a demo app if you want to see how it all works.
There are hundreds of books and thousands of articles on color and color theory but why is it that coming up with a great pallet for your UI is still so difficult? In this article, self-taught UI designer @erikdkennedy lays out his practical framework for coming up with a pallet that actually works.
With many developers still in the process of migrating their code bases from Objective-C to Swift, having mix-and-match code bases is not unusual. There’s been some good news this week if this is you as the arrival of the first beta releases of Swift 3.1 brings with it new compiler capabilities that allow the use of precompiled bridging headers that remove the need to repeatedly parse the header file and with it bring up to a 30% reduction in build time for debug builds. Great to see things continuing to improve.
Continuing his study of the Swift Language, @olebegemann looks at some more advanced uses for String interpolation in Swift such as when using it to store and manipulate HTML text. It’s an interesting read.
As we’ve seen, Strings play a pretty major part in most Swift development and under the hood are much more complex than you may expect. With the focus of the Swift Evolution community now turning toward Swift 4, the String Manifesto for Swift 4 is an interesting read if your looking to get a view of the future direction of Strings in Swift.
When introduced into Swift, the concept of optionals was a little frustrating for many. However, in practice they have been a great addition to the language and have helped address many of the ‘messaging nil’ issues that used to occur with Objective-C. However, there are still occasions when you want to do things with optionals that are a little beyond their built-in capabilities. @xenadu02 looks at a few of his favourites.
Testing asynchronous code came along way with the introduction of Xcode 7 but the new Xcode 8.3 beta builds have built on this introducing a couple of new classes to help with waiting for expectations in asynchronous code. @joemasilotti provides a useful introduction.
CalendarKit by Richard Topchii is a fully customizable Swift framework designed to look similar to the iOS calendar out of the box whilst also supporting a wide range of customisations. Looks to be a good option if you need to build calendar functionality into your own app.
If you’re a fan of Reddit this library from @sonson_twit might be the one for you. Written in Swift, Reddift is an API Wrapper for Reddit supporting both OAuth2 authentication and multiple accounts although there is no support for tvOS yet.
If you’re currently looking for an alternative to
UIAlertController then SCLAlertView might be worth a look. Written by @vikmeup it’s written in Swift provides a good range of customisation options for you to play with.
With the closure of Parse last Saturday (28th Jan), many people will have moved their back-end solutions to pastures new. However, if you’ve been dragging your feet or forgot about the deadline @vixentael has just published a great tutorial on how to get it’s Parses open-source alternative up and running on Digital Ocean.
We’ve all got them. Maybe it’s that ever growing list of side projects that are collecting digital dust somewhere on our hard drive or that list of project ideas you’ve never got off the ground. Whatever it is, this article from @purpleyay has some great tips that might alter how you view these side projects in future. 👏