This Week's Sponsor:

Albums

Algorithm-Free Listening for Music Lovers

Posts tagged with "developers"

iTunes Connect’s App Analytics Adds Source and Referrer Data

Two years ago, Apple rolled out App Analytics on its iTunes Connect developer portal. Originally announced at WWDC in 2014, App Analytics gave developers a better understanding of how and when their apps were used, how many views their app’s page on the App Store received, and more. However, the original version of App Analytics did not report how customers got to the App Store.

Yesterday Apple announced an expansion to App Analytics that adds source and referral data. According to Apple’s developer news website:

App Analytics in iTunes Connect now provides insight on where customers discover your app, including App Store browsing and search, within other apps, or on the web. With key metrics based on source types, you can see your top referring apps and websites, making it easier to optimize your marketing campaigns.

Apple’s App Analytics page elaborates:

With App Analytics, you can see how many users discover your app while searching or browsing the App Store — including tapping on Search Ads for your app — to gain insight into how your marketing and metadata impact downloads.

App Analytics counts users who visit your app’s product page from a link within another app.

Blogs, websites, and other online sources that link to your app’s product page, are critical in driving user acquisition through word-of-mouth marketing and PR. With App Analytics, you can see which organic marketing channels drive the highest traffic, downloads, usage, and revenue for your app.

There is a lot of interesting new data for developers to digest in App Analytics that should help them market their apps more effectively. I particularly appreciate the ability to drill down into any source of App Store traffic to see how it has performed over time and from which countries those customers are coming.

Apple Updates TestFlight with Improved Testing Options

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.

The 2016 Panic Report→

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).

Permalink

Curtis Herbert on App Store Review Replies→

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.

Permalink

Details on App Store Developer Responses

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.

The iMessage App Store’s Discoverability Problems→

Adam Howell sums up some of the major issues affecting the iMessage App Store and iMessage apps:

I love the idea of the iMessage App Store. I love Apple’s focus on privacy. I love building on top of an app I use all day everyday. But not only is the iMessage App Store dying —I’m afraid it might already be dead.

I agree with most of his design and functionality-related points. Using stickers and iMessage apps requires too much effort; a lot of users are still confused by iMessage-only apps; and I don’t understand why Apple thought Digital Touch was so important. I like his proposed solution for iMessage app activation, too.

On curation, though, I believe Apple has been doing a decent job with refreshing featured apps and sticker packs on weekly basis. A few months ago, Apple’s editorial team also started highlighting iMessage apps and stickers on the front page of the iOS App Store, which must drive some visibility. Every week, we discover new stickers to feature in our newsletter also thanks to Apple’s curation and the store’s top charts, which are dominated by Disney stickers as it’s a massive brand that has absolutely nailed the idea of selling “premium” iMessage sticker packs.

Aside from design and functional issues (in short, Apple should redesign the entire iMessage app drawer), I think the reality most iMessage apps are facing is a repeat (at a smaller scale) of what happened with the main App Store. Apple should make meaningful improvements to make developers’ lives easier, but it’s always going to be a tricky business to figure out in such a competitive landscape.

Permalink

iOS 10.3 Beta Adds ‘App Compatibility’ Screen Listing Old 32-Bit Apps→

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.

Permalink

Making More Outside the Mac App Store→

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.

Permalink

iOS 10.3 Beta Re-Introduces Warning for Old 32-Bit Apps, Suggests Future Incompatibility→

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.

Permalink