Issue 398

Comment

Last night I was catching up on the week's iOS news and I found myself nodding along with point after point in this article on Apple's long term Marzipan strategy from Curtis Herbert. As I've said before I'm not expecting huge changes to Marzipan over what has been discovered over the last 12 months, but I'm definitely expecting some.

So far most of the criticism has been around things like platform fit, but Curtis makes the point that there are many things that are needed before that can be the top priority:

The real can of worms opens before we even get to worry about if our apps look at home on the Mac: it begins in just worrying about getting them to run. That means every framework we use on iOS has to be there on the Mac, in some form.

He's got a point, macOS and iOS have separated significantly over the years with so many iOS only APIs being introduced. He suggests that one focus of this year's Marzipan release might be something less susceptible to criticisms of platform fit, games.

To me games seem like they'll be the low-hanging-fruit of a v1.0 Marzipan rollout as they'll require the least framework surface area to support. Their AppKit support needs will be minimal too: keyboard/mouse support, a menu bar item or two, and boom(ish) you've got a native-feeling Mac game.

He's not saying that the Marzipan story will be entirely about games (and I also hope it isn't!), but that they may well feature prominently. I do worry that given how much negativity there has been in our community about Marzipan, that whatever they announce this year will only be seen as disappointing.

So what I really hope for in June is that Apple map out their strategy for Marzipan with a little more clarity. Obviously they're not going to give us any information on things like ARM based Macs, but that doesn't mean they can't let us in on the software roadmap a little bit. If platform fit is taking a back seat this year over framework compatibility and games, that's OK but it does mean the wailing and moaning will be deafening for the next 12 months if that's all they present.

They probably won't, but I can live in hope... 🤞

Tools

Populating your app with test data using Xcode

Here's a couple of short Twitter tips to kick off this week's Tools section. 👍 First up is Carola Nitz on using a downloaded version of your app container's data as source data for your tests. There's a follow on tip in the replies too.

Deleting unused iOS Simulators

Next up, and especially if you're short on disk space, you might want to consider this tip from Julio Carrettoni. Just be careful to only do it if you only have one version of Xcode installed.

Xcode Search Scopes

Finally, another small tip (but not on Twitter this time) from Paulo Andrade on powering up project search in Xcode. I'd say we could all save a bit of time with this one.

Code

Core Image Filter Reference

I remember when Core Image first launched on iOS and there were only about 15 filters that had been ported across from macOS. That's certainly not the case any more though and you may need some help figuring out which one you need. Enter Noah Gilmore with his new CIFilter documentation site. There's an app too, if you want to test them out.

Blueprint: Declarative UI construction for iOS

Are Apple working on a declarative, Swift only UI API for us to use in the future? Maybe! But why wait for that when you could give this one from Tim Donnelly a go instead? It works alongside UIKit so you don't have to adopt it wholesale if you do decide to give it a try.

Structuring Your iOS App for Split Testing

Do you do A/B testing in your app? If you do, has it started to spread havoc in your codebase? Arlind Aliu has some advice on how to cleanly add split testing of content, design and behaviour to your app.

State Restoration With Swift Structs

I love apps that take state restoration seriously and make sure I end up back where I was no matter whether or not the app has been silently terminated in the background since I last used it. Keith Harrison gives us a way to use Sourcery to make the implementation of it a little easier.

Up to Speed

It's time to break up with your networking library for URLSession

I've said this a few times over the years but the reasons for using a third party networking library get fewer and fewer every year. I liked this article by Tim Miko on how to build a simple API client with no dependencies. There's a simple playground example too.

And finally...

A new standard in bad release notes...

It's not even about the bad capitalisation, or typo in one of the three words… How can you make "Bug fixes and performance updates" even less descriptive? Someone found a way! 😂

Subscribe with

Issue 398 April 5th 2019