Fascinating deep dive by Craig Morey on whether it's possible for a front-end web developer to get their work on an iPad Pro in 2018.
It's a highly technical read, and ultimately Morey doesn't believe an iPad Pro is ready for this task yet, but it's worth pointing out that many of the issues outlined by Morey are applicable to anyone who uses an iPad as their primary computer today. For instance, the problem with Files APIs, introduced in iOS 11 and still not widely adopted by third-party document-based apps:
I’ve already posted about the messy landscape of options for moving and accessing files in iOS. The only way apps should be doing it currently is with iOS 11 style file APIs, but many apps have either legacy file solutions, bespoke (ie, confusingly different — and differently-abled) file pickers or would rather pull you into their own cloud platform.
Apple need to evangelise the right way to do this before basic file management turns off the potential users before they get to the inspiring parts of iPad usage. But to really make it work, app developers need assistance to update older apps to the latest APIs. Many app devs spent huge amounts of time building custom solutions before any good options existed, only to see little in terms of revenue to encourage them to rewrite their app as new APIs came along. The iPad Pro marketplace needs to be turning a corner in terms of viability to bring these apps back into the modern iOS world.
Make sure to watch the videos in Morey's piece – I love how he detailed every single step of the workflows he tried to build on his iPad Pro.
To help developers take advantage of the latest features of the iPad Pro and Apple Pencil, Apple has posted two new videos to its developer portal. Even if you aren’t a developer though, the videos include interesting insights on some of the unique features of the new iPad Pros.
The videos cover development and design issues that should be considered when adapting apps to the new iPad Pros like using safe area insets to avoid crowding content into the rounded corners or under the home indicator. Another consideration to take into account is that unlike the previous iPads, the 11” iPad Pro doesn’t have a 4:3 aspect ratio, which means apps hard-coded to those dimensions will have areas cut off at the top and bottom.
Also, apps that don’t link against the iOS 12.1 SDK will run in a compatibility mode when multi-tasking, which will add an inset at the top and bottom of the screen for both apps instead of running them fullscreen. Apple says that making sure iPad apps can handle the inset compatibility mode will also help with bringing iOS apps to the Mac in 2019.
The Apple Pencil has a set of default double-tap settings that we covered in our iPad overview, but developers have the option to customize the double tap action in their apps. Apple also encourages developers not to hide functionality behind the gesture or turn custom actions on by default.
The videos cover the iPad Pro’s new USB-C connector too. The iPad Pro supports HDR 4K up to 60Hz and external displays up to 5K as well as USB audio devices, Ethernet, and MIDI. The iPad Pro can also send simultaneous USB-C outputs, which permits uses like connecting a DSLR Camera and 5K display to the iPad Pro at the same time.
The new videos are available as part of Apple’s Tech Talk series.
You can also follow all of our Apple event coverage through our October 30, 2018 hub, or subscribe to the dedicated October 30, 2018 RSS feed.
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.