Yesterday Apple launched TestFlight 1.5 on the App Store. The update's release notes didn't highlight any specific changes, but developers are discovering today that its release was timed with a few major updates.
Developers can now create different builds of an app to be distributed to different groups of testers. These changes will make A/B testing of apps possible for the first time, so developers can gauge feedback from different groups who are testing different versions of the same app.
Multiple builds can also be distributed to the same people so that testers can choose from a variety of builds that they wish to test.
Longer testing periods is another change – up from 60 days to 90 days. These are not yet noted in Apple's official documentation, so they are likely still in the process of rolling out. Developers we've spoken with as well as the MacStories team have been able to see builds with an expiration time of 90 days.
From Cabel Sasser's latest Panic report (as always, a great read):
If you remember, 2016 was the year we killed Status Board, our very nice data visualization app. Now, a lot of it was our fault. But it was another blow to our heavy investment in pro-level iOS apps a couple years ago, a decision we’re still feeling the ramifications of today as we revert back to a deep focus on macOS. Trying to do macOS quality work on iOS cost us a lot of time for sadly not much payoff. We love iOS, we love our iPhones, and we love our iPads. But we remain convinced that it’s not — yet? — possible to make a living selling pro software on those platforms. Which is a real bummer!
Giving more tools to companies like Panic to make professional, powerful software for iOS is one of the challenges Apple faces along with making the OS itself more capable. There should be more iOS-first and iOS-only Panics and Omni Groups around.
See also: last year's episode of Remaster on Firewatch (which you should go play right now if you haven't).
Curtis Herbert, creator of the excellent Slopes for iOS (I wish I was a skier or snowboarder to use his app), has some great tips for developers on dealing with replies to App Store reviews:
I'd recommend every app owner do the following, today. Head into the review section in iTunes Connect and sort by "Most Helpful." These are reviews that customers have voted should be floated to the top, and that's what Apple does. Take a quick look through there and see which ones you can address.
Future customers are most likely to see your replies to these reviews, so that's the best bang-for-the-buck you can do right now. I went further than that, personally, and re-read a ton of my negative reviews and replied to the ones that met the above goals, but you don't have to rush it.
If you're a developer, you'll want to start engaging with customers right away and work through your existing backlog of reviews. I have a feeling the new ability for developers to reply to customers will fundamentally change the tone and utility of App Store reviews.
Following yesterday's release of iOS 10.3, which introduced the ability for developers to respond to App Store reviews, Apple has released official guidelines for how developer's can best craft responses.
The ideal response is concise and clearly addresses your customer's feedback. Communicate in the tone of your brand, and use terminology your target audience will appreciate and understand. If multiple people in your company can reply to reviews for your app, they should use a similar voice and style. Make sure your replies follow Apple’s Terms and Conditions, which prohibits using profanity, posting users’ personal information, and spamming.
The guidelines also recommend:
- Always providing individualized responses, even if only by pairing a personalized introduction with a more generic response.
- Soliciting feedback from users regarding what they'd like to see in future updates.
- Replying to reviews in a timely, consistent manner.
- Prioritizing responses based on a review's apparent level of importance.
- Writing release notes for app updates that specifically address issues mentioned in past reviews, and letting those past reviewers know of the update.
- Staying on topic with the issue raised by a review; no using replies as a means of advertisement.
Besides these guidelines from Apple, as App Store responses have gone live for the first time, more details have come out concerning how those reviews will work.
It appears that every reply submitted by a developer goes through some sort of review process before it is posted to the App Store. In the following tweet's screenshot, you can see a 'Pending' tag on the developer's review.
It was previously unknown how users would be notified when a developer responds to their App Store review. Although a notification from the App Store app seemed a possibility, Apple has instead chosen to go the route of email notifications. Those emails include a link with the option for reviewers to update their original review.
In addition to a new warning displayed upon launching an old 32-bit app for the first time, it appears that iOS 10.3 will also include a Settings page listing legacy apps that "will not work with future versions of iOS".
Juli Clover, writing for MacRumors on the latest iOS 10.3 beta released earlier today:
In the Settings app, there's a new "App Compatibility" section that lists apps that may not work with a future version of iOS. Tapping on one of the apps opens it up in the App Store so you can see when it was last updated. As has been discovered in previous betas, opening one of these apps on your iOS device pops up a warning with a similar non-compatible statement. App Compatibility can be accessed by opening the Settings app and choosing General --> About. From there, scroll down to "Applications" and tap it.
It's not clear whether these warnings will make it into the final release of iOS 10.3, but they're a strong sign that developers should prepare for stricter 64-bit requirements in iOS 11.
After seeing the results of Kapeli's exit from the Mac App Store, Rogue Amoeba's Paul Kafasis compared sales of Piezo from the Mac App Store and their direct web store as well:
After seeing Kapeli’s chart, I was curious about the App Store’s impact on Piezo’s sales. The restrictions and limitations of the Mac App Store ultimately led us to remove Piezo on February 12th, 2016. We’ve now been selling it exclusively via our site for a year. This has provided about as perfect a real-world test case as one could hope for. Piezo’s removal came with minimal publicity, the price has remained constant at $19, and we’ve had no big updates or other major publicity for it in either 2015 or 2016.
His conclusion is perfectly reasonable:
In our case, however, it’s clear that we were serving Apple, rather than Apple serving us. By removing Piezo from the Mac App Store, we stopped paying a commission to Apple for the many customers who had found Rogue Amoeba on their own. Better still, we were able to improve the quality of the product while simplifying our work considerably. Ultimately, that alone was enough to convince us that leaving the Mac App Store was the right move. The subsequent revenue increase we’ve seen is merely a nice bonus.
At this point, I don't understand why any independent developer would want to sell apps exclusively through the Mac App Store. The lack of meaningful improvements since 2011 don't justify Apple's high commission anymore. The Mac App Store has always been a second-class citizen; today, Mac developers like Rogue Amoeba are better served by controlling their own destiny.
Andrew Cunningham, writing for Ars Technica on a new warning that appears when running old 32-bit apps on the first beta of iOS 10.3:
Beta builds of iOS 10.3, the first of which was issued last week, generate warning messages when you try to run older 32-bit apps. The message, originally discovered by PSPDFKit CEO and app developer Peter Steinberger, warns that the apps "will not work with future versions of iOS" and that the app must be updated by its developer in order to continue running. The apps still run in iOS 10.3, but it seems likely that iOS 11 will drop support for them entirely.
Though the error message doesn't explicitly mention the app's 32-bit or 64-bit support, it's definitely only older 32-bit apps that trigger the warning. Similar messages that did explicitly mention 64-bit support were present in the betas of iOS 10.0, but they were removed in the final release of the software. Apple has required 64-bit support for all new app submissions since February of 2015 and all app update submissions since June 2015, so any apps that are still throwing this error haven't been touched by their developer in at least a year and a half (developers could add 64-bit support as early as 2013, but most of them opted not to until it became a requirement).
Note how, unlike the warning that was reinstated with iOS 10.1, this alert clearly states that "this app will not work with future versions of iOS" as opposed to "may slow down your iPhone".
In my review of iOS 10, I had a couple of paragraphs on the warning that iOS displayed when launching a 32-bit app for the first time. The warning didn't make it to the final version of iOS 10, so I didn't cover it. I did, however, note that iOS 10 was accelerating the transition to 64-bit across the board.
Requiring apps to be compiled for 64-bit is going to introduce problems for software that is no longer maintained (especially classic iOS games), but Apple is moving toward cleaning up the App Store's back catalog anyway. Enforcing the 64-bit requirement in iOS 11 wouldn't be a complete surprise.
Charles Joseph, developer of Picky, on the enhancements coming to the MediaPlayer framework in iOS 10.3:
I was genuinely surprised and elated to find that yesterday’s iOS 10.3 beta finally adds what looks like proper queuing functionality to
MPMusicPlayerController and I excitedly tweeted about it. Scott Edwards asked if I could “explain why that’s important to a non programmer”, so I’m going to try to do that here.
Alternatives to Apple’s Music app (like Picky) need to be able to access and play the user’s iTunes library, unless they’re part of a streaming service (like Spotify) or providing their own syncing and library management and companion apps (quite the tall order). While developers can build incredibly advanced playback functionality with tools like AVFoundation, that’s only possible for an increasingly smaller subset of users’ libraries: only locally downloaded, non-DRMed content — nothing stored in the cloud and nothing downloaded from Apple Music. People are storing more and more of their music in the cloud and expect third-party apps to be able to keep up.
It sounds like Apple is listening to feedback from developers of third-party music players. The changes documented in the iOS 10.3 beta so far don't address all the concerns Allen Pike covered last year, but it's a good first step. I'm curious to see how apps will take advantage of the improved API.