I worried that “Metal” had become Apple's version of “Blast Processing,” a catch phrase in the 90s for the Sega Genesis. In commercials, Sega would gloat that only the Genesis had “Blast processing.” The only problem was, Blast Processing didn't really do anything that mattered.
But it turns out, I was wrong.
Metal for OS X is huge — and it's going to be a much bigger deal on the Mac than it is on your iPhone or iPad. If you use a Mac to produce professional content, chances are, Metal is about to drastically speed up the professional apps you use like Adobe Illustrator and Autodesk Maya.
Writing for iMore, Brianna Wu explains why Metal for OS X – announced at WWDC 2015 – will be a big deal for games and professional apps on the Mac. It was great to see Campo Santo in Apple's slides, too.
Nick Arnott has taken a look at TestFlight a year after its relaunch and I agree with his overall take. I write about apps for a living (I currently have 74 betas in my TestFlight), and the simplicity of Apple's system is unparalleled. I just need to give developers my email and that's it.
I also agree with Nick's comments on frustrations with using TestFlight. I hope that Apple will continue tweaking these aspects going forward.
I've experienced a few minor frustrations with as a user though. For example, I can't accept an invitation from my computer — I have to accept an invitation from the device I want to test on. Also, TestFlight emails don't contain any release notes. With other services like HockeyApp, developer release notes are included in the email, so you can decide from the email if you care about the update or not. Lack of these release notes from TestFlight means you'll have to tap through to the app and view on your testing device to see if you want the update or not.
Sally Shepard has launched a Kickstarter campaign for the Inclusive Toolkit, a set of tools to help developers make iOS & OS X apps inclusive and accessible.
From the project's page:
The common difficulties around implementing inclusive concepts in apps are a lack of resources, knowledge and empathy. All of Apple’s products have features that enable inclusivity, and they make a huge difference to people’s lives. Anyone developing for their platforms has access to the APIs to make their app equally accessible.
So how can we fix this?
From a user point of view, I want the Inclusive Toolkit to help solve two problems: unusable elements and poor experiences. And from a developer/designer/QA point of view, I want it to speed up development and testing time, as well as build empathy. It’s great if you work in a company that already has specific resources and knowledge about accessibility—but for many developers, that isn’t the case. I want to provide ways of making it part of the development process instead of something tacked on at the end.
Make sure to check out Sally's ideas for the Inclusive Toolkit, such as 'Visual Voiceover' and ways to simulate impairments in the app testing process. Too many developers still ignore inclusive design and features in their apps, and anything that could help them simplify implementing these frameworks is, I believe, welcome and necessary.
Almost a year after the original announcement at WWDC 2014, Apple has opened access to App Analytics in iTunes Connect today.
Sarah Perez, writing for TechCrunch:
Ahead of its annual WWDC developer conference in June, Apple has opened up beta access to a new mobile app analytics service aimed at iOS developers. Simply called “Apple’s App Analytics,” an announcement inviting developers to request early access to the service appeared today on the iTunes Connect developer portal. Those with an iTunes Connect account can also reach the sign-up page using the direct link analytics.itunes.apple.com.
App Analytics are available for devices running iOS 8 and above, and the usage data part is completely opt-in. Every time you set up a new iOS device (or upgrade to iOS 8), you're asked if you want to share information with app developers to improve their apps through analytics. Other App Store metrics (views, installs, etc.) are returned for all users.
Based on the tweets I saw in my timeline today, first impressions seem positive. Apple can now give developers a level of insight that's unprecedented for any other app analytic platform. Apple's App Analytics can plug directly into the App Store and tell developers how customers find their apps, where traffic is coming from, and how many views an app gets on the Store.
After years of no data about customer behavior on the App Store, it seems like this will be a massive change for how apps are marketed, optimized for international App Stores, and presented to users.
Perhaps unsurprisingly, Apple updated their App Store Review Guidelines to state that Watch apps built primarily to tell time will be rejected.
In the past few weeks, I've heard about a few timezone apps primarily designed to show world clocks that were rejected for unknown reasons, with developers annoyed about the lack of official guidelines. Today's change is better than approving and then rejecting an app, I guess, but maybe Apple could have shared this piece of information sooner. I don't know if those timezone apps ended up being approved or not, and there could be other developers with a different experience from the ones I talked to.
From Apple's standpoint, however, I can see why it makes sense to avoid confusion with apps that replicate a watch face UI – at least initially. It's not too dissimilar from Apple's stance on third-party apps that replicated native functionalities with the original iPhone App Store.
Jeremy Olson on making Hours free and shifting their focus on turning a “simple app” into a business:
How do you break into business and the enterprise? We like Slack’s bottom-up approach. Start by making the best solution for individuals, who in turn advocate adoption for their team, who in turn evangelize to other teams…and up the chain it goes. If startups can make this strategy work in the Enterprise, as Slack has, then they can focus on creating a great experience for the end-user instead of a bloated feature list to pass a corporate approval checklist.
Hours is an excellent time tracker. I'm curious to see if this strategy will work out for them, and if other developers are tweaking their plans to follow a similar route.
See also: Dan Counsell's advice from last year.
After approving Watch apps from select developers last week, Apple has begun accepting submissions for Watch apps from all registered iOS developers. From the company's developer blog:
It’s time. Apple Watch will be in the hands of customers on April 24. Get your WatchKit apps ready and submit them for review now.
Apple has also created a new webpage titled 'Preparing Your App Submission for Apple Watch' with details on what developers should do before submitting an Apple Watch app to the App Store. There are some interesting tidbits on this page, such as limitations for app previews, which must show only iPhone apps:
Your app preview may only use footage of your iPhone app, and footage must stay within the app. Do not change your preview to show your WatchKit app.
And a note that suggests apps from third-party developers will be approved before April 24 and therefore used by people with a pre-release Watch unit:
Once your WatchKit app is approved and released by Apple, your existing iPhone users will receive the app update and customers will see your WatchKit extension icon and description on the App Store. A small group of people who currently have an Apple Watch will be able to use your WatchKit app before April 24, so make sure your back end systems are ready.
As I wrote last week, releasing Watch apps before the April 24 launch is a smart move from Apple:
For the first time in several years, a new Apple product will be reviewed by people who have access to third-party apps from the App Store. When the iPhone launched, there was no App Store; when the iPad launched, reviewers didn't have access to public downloads from the iPad App Store.
That won't be the case with Apple Watch, and this is a clever choice from Apple. Because the Watch is many things, it needs apps to offer a more complete picture of its potential. By approving the first Watch apps this week, reviewers (and customers at the try-on sessions in the retail stores) will get access to a selection of third-party apps that can show how the Watch will integrate in everyday life through the apps they already use.
Robleh Jama is the founder of Tiny Hearts, an indie iOS development company that ended up having one of their apps, Quick Fit, featured in an Apple commercial (this one). In an article for Fast Company, he shares some details of the selection process as well as good advice for developers. I liked this bit about localization (which is reflected in the app's performance in international markets):
One of the best decisions we made early on was to support multiple languages with Quick Fit and Wake Alarm. We focused on the key regions Apple recommends in its internationalization guidelines. Apps are a global phenomenon with millions of non-English-speaking users. We didn’t want to limit our goal of helping people get fit to just English speakers, so we localized our app's interface, description, and even screenshots.
We’re always trying to think of new and interesting stories to publish on MacStories, and often times they’re articles that are a complete experiment that we honestly don’t know how they’ll turn out – this is one of those articles.
Earlier this year I published an article that was essentially just a list of indie iOS/Mac developers and we got a great reaction to it (and we promise an update is coming). Inspired by the developers featured in that article, I asked a handful of them to write a journal of what they do in a week of development, and for some crazy reason, they agreed to contribute. Those generous developers are (in no particular order) Oisin and Padraig from Supertop, David Smith, Philip Simpson from Shifty Jelly, Greg Pierce from Agile Tortoise, and Junjie from Clean Shaven Apps.
I asked each of the developers to keep track of the work they did in the week of Sunday 22 February to Saturday 28 February. But I wasn’t specific in the format, other than to say I wanted something along the lines of a journal crossed with a time sheet. That was partly because I really didn’t know what would work well, but also because I wanted to be flexible and let the developers just write what they thought was appropriate. I had no idea what to expect, and was a bit nervous that the whole thing might fall apart because I hadn’t been specific enough about what I was looking for.
Fortunately, the result is fascinating, I found myself not only entertained but educated as I read through each of their journals. You’ll find that each journal is quite vastly different, not just in their writing style but also how they work as an indie developer. I know it’s a long read (certainly longer than I had anticipated), but stick with it – there are some great surprises throughout.