Archive for January 13, 2022

Thursday, January 13, 2022

An Approach for Migrating From Objective-C to Swift

Steve Barnegren (tweet):

It was difficult to gracefully integrate new Swift code into existing Objective-C classes and systems. A year down the line we still had a mostly Objective-C code base. Almost anything of any real importance was still in Objective-C, and all we’d really built was some surface level Swift on top of an Objective-C core.

[…]

Everything that’s great about Swift has to be sacrificed for Objective-C interoperability. Value types, generics, enums with associated values, optionals.

If you have a whole bunch of Objective-C and you write a tiny bit of Swift in the middle, then that Swift ends up being crappy Swift.

[…]

The key is that we start with a small Swift ‘island’. It can be just be one Swift class. We write nice Swifty code that we can be proud of, and then we provide shims that our Objective-C code uses to interface with it.

[…]

It may seem like overkill to have an Objective-C shim for a Swift wrapper around an Objective-C type, but remember this is all a means to an end. If we’re making good progress on our language transition then we’re deleting shims as fast as we’re creating them.

Nick Lockwood:

Steve makes a great point here. Swift shines brightest at the model layer, where its strong types help you architect a better foundation for the whole app.

Adding some Swift views on top of Obj-C and then working your way down won’t get you there.

I concur. Writing Swift on top of an Objective-C base is not a great experience and doesn’t provide a lot of benefit. But substituting in a Swift base is non-trival because most of the features can’t be used from Objective-C. Even sticking with reference types, you can’t subclass a Swift class from Objective-C. Hence the need for techniques like Barnegren mentions if you can’t rewrite everthing at once.

Update (2022-01-17): Steve Troughton-Smith:

A lot to unpack here, but yes, your Cocoa-oriented data model is absolutely gonna be the worst and most frustrating point of transitioning to Swift. It just doesn’t fit the way everything else works, and forces you into way more potentially-problematic boilerplate than you want

iOS App Library Is Drunk

Jesse Squires:

Periodically, the order of folders in App Library changes. Why?! It is incredibly disorienting. I’m not sure if this is a bug or a “feature” where recently-used or most-used categories move toward the top? The order of category folders should always be fixed.

The second major issue I’ve seen lately: sometimes apps change categories. The other day, Duolingo suddenly moved from “Education” to “Other”, along with a few other bizarre moves. This certainly seems like a bug, but I really don’t understand how this could happen. Presumably, these categories are based on the App Store categories that developers select for their apps, and which are part of an app’s metadata. Apps should only change categories if the developer changes the app metadata.

Previously:

Uber Removes Watch App

Chris Welch:

Uber has quietly shut down its Apple Watch app, with the software now showing a message that instructs people to “please switch to the Uber mobile app.” The company is “no longer supporting the Apple Watch app,” according to the text, which ends with Uber apologizing for any inconvenience caused by the app’s discontinuation. There’s also a sad face emoji to drive that sentiment home.

[…]

On the one hand, this is another example of smartwatches continuing to shed apps — even those that are massively popular and borderline essential on a phone — that aren’t core to their purpose(s) of fitness tracking, notifications, music playback, and so on. I’ve long had Uber installed on my Apple Watch, and I don’t think there was a single occasion where I hailed a ride from my wrist.

[…]

But it also goes to show that, in some ways, smartwatches are only moving further away from being able to serve as a standalone smartphone fill-in — even temporarily.

I wonder whether this is because the apps didn’t get much use, with people preferring the app on the phone that they carry anyway, or because no one seems to like the experience of developing and testing for watchOS.

Jesse Squires:

I think many apps simply don’t make sense on the watch. I would not install any of the above apps, for example. But even apps that do seem to belong on Apple Watch remain awful. In my earlier post, I mentioned how RunKeeper was no match for the built-in Workout app. RunKeeper is glitchy, flakey, and has a significantly inferior UI compared to the Workout app.

At this point, the only third-party watch app that I have installed is Spotify.

Previously:

Update (2022-01-17): Casey Liss:

Having spent a LONG time last year futzing with watchOS, I can tell you that in my experience, the limits are still that bad. As is the dev experience.

Perhaps others feel differently, but I shit-canned an entire app because the watchOS experience turned me off that much.

iCloud Private Relay Incompatible With T-Mobile Parental Controls

Chance Miller (tweet):

Earlier today, a report indicated that some European carriers were blocking the Private Relay feature introduced by Apple with iOS 15. This feature is designed to give users an additional layer of privacy by ensuring that no one can view the websites that they visit.

Now, in addition to some carriers in Europe, it appears that T-Mobile/Sprint in the United States is also blocking iCloud Private Relay access when connected to cellular data.

Juli Clover:

iOS 15.2 did not introduce a bug that turned iCloud Private Relay off for some users, Apple said in a statement that was provided to MacRumors. The statement was in response to a T-Mobile claim that iOS 15.2 had automatically toggled the iCloud Private Relay feature off for some users.

[…]

Apple also said that no carriers, including T-Mobile, have blocked their users from taking advantage of the iCloud Private Relay feature.

[…]

T-Mobile also said that customers who have plans and features that use T-Mobile content filtering, such as parental controls, do not have access to iCloud Private Relay in order to allow these services to work as designed. It is not entirely clear why some T-Mobile subscribers were having issues, but customers who are not using content filtering should be able to use iCloud Private Relay as expected.

[…]

At least some of the confusion over T-Mobile and iCloud Private Relay may be related to the wording of the setting in the current version of iOS 15.2, which says that iCloud Private Relay is not carrier supported even if the feature is actually toggled off by the user in the cellular settings.

That wording sounds like it’s right up there with App Store support telling customers to ask the developer for a refund.

Previously:

Update (2022-01-17): Rosyna Keller:

Apple has updated the iCloud Private Relay support document to help clarify some of the problems users experienced.

Specifically, that you can toggle Private relay on or off per-network (cellular data, specific wi-fi networks, et cetera)