In a brief post on Apple’s Developer news site, the company announced that it is adding support for app bundles to the Mac App Store. According to the post:
…now, you can create app bundles for Mac apps or free apps that offer an auto-renewable subscription to access all apps in the bundle.
The post points to developer documentation on creating app bundles that that has been revised to mention Mac apps. The process for setting up a bundle, which will allow developers to offer up to 10 Mac apps as a single purchase, appears to be the same as it is for iOS developers. Unfortunately for those developers with iOS and macOS apps, it does not appear possible to create a mixed bundle of iOS and Mac apps.
Last week we linked to Marco Arment’s article critiquing Apple’s watch faces and calling for Apple to open up watch face design and development to third parties. By the next day, Steve Troughton-Smith had an Xcode project up and running that uses SpriteKit to simulate custom watch faces. Troughton-Smith posted pictures of the watch faces he created on Twitter, which drew a lot of interest from other developers.
Troughton-Smith uploaded his watch face project to GitHub, and in the days that followed, developers, including David Smith, who’s been making Apple Watch apps for his health and fitness apps since the Series 0 was introduced, began playing with Troughton-Smith’s code. Writing about the experience on his website Smith said:
There is something delightful about solving a problem that is superficially so simple and constrained. The constraint leads to lots of opportunities for creative thinking. Ultimately you just need to communicate the time but how you do that can take countless different forms. It reminds me of the various ‘UI Playgrounds’ that have existed in app design. For a while it was twitter clients, then podcast players and weather apps.
I spent the weekend following along as Troughton-Smith, Smith, and others designed all manner of personalized watch faces. The experience reminds me of the flurry of activity and excitement during the first months after the iPhone was released when developers reverse-engineered Apple’s APIs to create the first jailbroken apps even before there was an App Store. Let’s hope that history repeats itself and Apple opens up watch face development to third parties like it did with apps.
Below and after the break, we’ve collected tweets following Troughton-Smith's work and showing off some of the designs that have been created over the past several days.
Benjamin Mayo, writing for 9to5Mac:
Apple is rolling out a new TestFlight feature which enables developers to share a public URL for an app beta. Customers can simply open the link on their iPhone or iPad and automatically enroll into the beta testing group through the TestFlight app.
This feature was announced back at WWDC in June but has only just started showing up for developers inside the App Store Connect interface. Previously to public links, developers had to manually ask people for email addresses and then send out invite in emails to each person individually.
As someone who's routinely testing dozens of apps for review purposes, this sounds a lot more convenient than the current email-based invitation system, both for developers and users. By default, developers don't see the names and emails of users who sign up with a link. I have a feeling this option is going to be frequently used for public betas with large pools of testers.
Many app developers already provide privacy policies and are transparent about the information they collect from users and how they use it. I’m glad to see privacy policies become a requirement though because for some apps it’s not easy to track down how they use your data and there have been too many instances in the recent past where it’s been discovered that an app has used data in ways that users might not expect.
Apple has updated the WWDC app ahead of its annual developer conference that begins June 4, 2018 in San Jose, California. Unlike last year, when the app received a new design inspired by apps like Apple Music and Apple News, this year the app has remained largely unchanged. Other than a new icon, the main change with this update is that the schedule for 2018 conference sessions is now included.
The most noteworthy news tidbit from browsing the app's updated schedule is that the Apple Design Awards are making a return to public form this year. At WWDC 2017, Apple decided to eschew its normal tradition of a public ceremony, and instead honored ADA winners in a private ceremony, followed by an updated website. This year marks a return to form, with the ADAs being held the evening of the conference's first day.
The WWDC app is a free download on the App Store.
Paul Miller, writing for The Verge, argues that Swift Playgrounds, while an amazing tool to learn the fundamentals of coding and Swift, ultimately doesn't let kids build real apps:
The Swift Playgrounds fantasy of what ARKit is like is closer to an ad than a tutorial. I’ve actually worked on an app using Apple’s ARKit and SceneKit APIs directly. I got stuck when my API call to Apple’s sound playback system wouldn’t work, despite all my best efforts at debugging. Writing software with Apple’s APIs is a powerful but difficult practice, and Swift Playgrounds’ penchant for hiding true complexity makes it hard to recommend for someone who doesn’t want to just “learn how to code” but instead wants to build something.
Apple would do its learners a huge service by providing them an Xcode equivalent on the iPad. Not because it would suddenly be easy to make applications and release them on the App Store, but because it would give iPad-bound learners a chance to engage that challenge and grow into true application developers in time.
I agree with Miller. I've been crossing my fingers for an iPad version of Xcode ever since the first-generation iPad Pro in late 2015. From aspiring programmers who would have a chance to see their creations on the iPad's Home screen (without using a Mac) to developers who could create commercial iPad software on their own iPads, the iPad needs Xcode. If coding is as important as learning a language, the lack of Xcode for iPad is like not having a keyboard to express our thoughts.
I’ve been keeping an eye on the adoption of the Apple Watch Series 3 since its introduction last fall. From a development perspective the Series 3 is a delight to work with. It is fast, capable and LTE allows a wide variety of new applications (for example, the podcast support I added to Workouts++).
This stands in contrast to the challenges of working with the Series 0 (or Apple Watch (1st generation) as Apple would call it). It is just slow and honestly a bit painful to develop for. Even basic things like deploying your application to the watch can take uncomfortably long amounts of time. In daily use the Series 0 is probably “good enough” for many customers, especially with the speed/stability improvements added in watchOS 4, but as a developer I can’t wait until I no longer have to support it.
Which is why I’ve been watching the Apple Watch adoption curve within my apps (specifically Pedometer++ for this analysis) quite carefully. My personal hope is that this summer when we get watchOS 5 it will drop support for the Series 0 and free Apple to really push forward on what is possible for developers. But in order for that wish to be realistic I imagine Apple will need the daily use of those first watches to have died down significantly.
These are fascinating numbers about the adoption of different Apple Watch models by David Smith, who makes some of the best apps for the platform.
I've been wondering about when Apple could drop support for the original Apple Watch in new versions of watchOS. For context, the original iPhone, launched in 2007, couldn't be updated to iOS 4 in 2010, three years later. The Apple Watch will have its official third anniversary next month. I suppose that Apple Watch owners hold onto their devices for longer, but if old hardware is stifling innovation for the developer community who wants to push Watch apps forward (as much as that is possible with the current tools), then maybe it is time for Apple to move on.
Whether you’re a developer who’s working on mobile apps, or just someone enjoying the millions of apps available for your phone, today is a very special day. It’s the ten year anniversary of the original iPhone SDK.
I don’t think it’s an understatement to say that this release changed a lot of people’s lives. I know it changed mine and had a fundamental impact on this company’s business. So let’s take a moment and look back on what happened a decade ago.
Craig Hockenberry published a fantastic retrospective on a decade of the iPhone SDK, which, after months of jailbreaking, allowed developers to start making real iPhone apps in 2008. It's an excellent, well-researched story (with a lot of links, which you should open in new tabs; take your time to explore) that brings back a lot of memories. You should also check out the replies (standard and quoted) to Craig's tweet for a lot more interesting stories.
It's not an exaggeration to say that I wouldn't be here, typing this post today, hadn't Apple decided to open iPhone app development to third-party developers 10 years ago. I think many of us in this community of people who still care about this stuff at least partially owe our careers to the iPhone SDK. I've shared this story before, but in 2008 I dropped out of university, got a job at a physical "eBay store", and later started blogging with a free WordPress website because I wanted to write about apps. But really, I wanted to write about iPhone apps and try as many as possible to share my thoughts with other people. That website eventually became MacStories and these words I've been putting out for almost 9 years now.
In hindsight, it feels strange that thousands of jobs around the world were created or inspired by a huge and sprawling corporation, but it didn't feel that way back then. Even as a nobody watching and blogging (in poor English) from the sidelines of a burgeoning industry, that period between the spring of 2008 and early 2009 carried a palpable sense of discovery, surprise, and wild experimentation that I remember fondly. I saw app developers as pioneers charting a future we couldn't even imagine. It was, in many ways, a different, ingenuous, more enthusiastic era – one that I hope to live through again someday.
Marco Arment (who's been struggling with Watch app development for a while now) makes the case for WatchKit to be either discontinued or substantially expanded as, in its current form, it hinders the creation of more powerful apps.
Developing Apple Watch apps is extremely frustrating and limited for one big reason: unlike on iOS, Apple doesn’t give app developers access to the same watchOS frameworks that they use on Apple Watch.
Instead, we’re only allowed to use WatchKit, a baby UI framework that would’ve seemed rudimentary to developers even in the 1990s. But unlike the iPhone’s web apps, WatchKit doesn’t appear to be a stopgap — it seems to be Apple’s long-term solution to third-party app development on the Apple Watch.
When I first read his post, I thought that asking Apple to discontinue and replace WatchKit was perhaps too much. But after spending some time reorganizing my Watch favorites and complications last night and this morning, I agree with Marco. My favorite apps on the Watch are all made by Apple and are not based on WatchKit. The only exception is Workouts++ (which, as a workout app, has specific privileges). The only third-party Watch apps I regularly use besides Smith's app are Things and Shazam (which is somewhat ironic) and they're both accessed via complications; they're okay, but I don't love them because they're often slow to sync data with their iPhone counterparts or take too long to launch and be in a usable state. When I'm out and about, I still don't trust Watch apps to be as reliable as iPhone apps.
Despite three years of watchOS updates and more powerful hardware (I use a Series 3), the Apple Watch still doesn't feel like the rich, diverse, and vibrant app platform that the iPhone is. Some might say that's precisely the point – it doesn't have to be because the Watch works best through notifications and complications. However, I often ask myself if such argument is the wearable equivalent of Aesop's sour grapes – real Watch apps wouldn't make sense anyway. Like Marco, I wonder what would happen if only Apple exposed real watchOS development tools to app makers.