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.
TLDR: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
- 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.
SKStoreReviewControllerclass and an associated
requestReview()method. 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.
Following a conversation with Apple, @gruber writes on daringfireball.net:
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).
UIApplicationseems 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. apple.com
Design@erikdkennedy lays out his practical framework for coming up with a pallet that actually works. medium.com
Swiftfirst 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. swift.org
@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. oleb.net
@xenadu02 looks at a few of his favourites. russbishop.net
Code@joemasilotti provides a useful introduction. masilotti.com
@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. github.com
UIAlertControllerthen 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. github.com
Other@vixentael has just published a great tutorial on how to get it’s Parses open-source alternative up and running on Digital Ocean. stanfy.com
@purpleyay has some great tips that might alter how you view these side projects in future. 👏 gwendolyn.io