Archive for October 6, 2017

Friday, October 6, 2017

AIM Will Shut Down After 20 Years

AOL (tweet):

AIM tapped into new digital technologies and ignited a cultural shift, but the way in which we communicate with each other has profoundly changed. As a result we’ve made the decision that we will be discontinuing AIM effective December 15, 2017.

Jacob Kastrenakes (via Hacker News):

AOL cut off access to AIM from third-party chat clients back in March, hinting at this eventual shutdown. It’s hard to imagine that many people are still using AIM, so that change, nor this upcoming shutdown, are likely to make a huge difference.

AIM was one of the first and most successful instant messengers, widely used in the late ’90s and even throughout the 2000s.

empath75:

I think it’s remarkable how badly aol fumbled the ball on AIM twice — first by not turning it into a social network, and second by not turning it into enterprise chat.

I didn’t use AIM much because I found it too distracting. Clearly the world has moved on, but it’s sad that replacements such as iMessage and Slack are less functional than AIM in certain ways and don’t have the rich ecosystem of third-party clients.

Cocoa Class Clusters

David Smith:

I was curious about how much mileage we get out of the class cluster pattern (spoiler: a lot!) so I catalogued some.

Apple Granted Uber a Background Screen Recording Entitlement

Kate Conger (via Felix Schwarz, MacRumors, Hacker News):

To improve functionality between Uber’s app and the Apple Watch, Apple allowed Uber to use a powerful tool that could record a user’s iPhone screen, even if Uber’s app was only running in the background, security researchers told Gizmodo. After the researchers discovered the tool, Uber said it is no longer in use and will be removed from the app.

[…]

“Essentially it gives you full control over the framebuffer, which contains the colors of each pixel of your screen. So they can potentially draw or record the screen,” explained Luca Todesco, a researcher and iPhone jailbreaker. “It can potentially steal passwords etc.”

If a user happened to have Lyft installed on their phone too, the entitlement could theoretically be used to monitor how the individual used a competitor’s app—a wild theory, maybe, but not entirely outlandish given Uber’s use of software nicknamed “Hell” to track drivers who worked for both Uber and Lyft.

[…]

The entitlement first appeared in Uber’s app around the time of the original Watch launch in 2015, according to Strafach. Apple only gave developers about four months before the official release of the Watch to slim down their apps and make them work on the new device, so it’s conceivable that Apple granted the entitlement to Uber in order to meet that tight launch deadline.

I don’t trust Uber to use this entitlement responsibly. Nor do I trust App Review to be able to police how the app is using it. It’s shocking that Apple would be so hypocritical about privacy and give special access to a known bad actor. I don’t jailbreak my phone, so I thought I knew that if I downloaded an app from the App Store there were certain things it just couldn’t do, especially without the OS prompting me to give it access. That’s apparently not the case. Fortunately, there likely aren’t many developers with enough clout to get this sort of special treatment.

Update (2017-10-09): Daniel Jalkut:

I have long felt that the sandboxing infrastructure on both iOS and Mac should be used to more accurately convey to users specifically what the apps they install are capable of doing. Currently the sandboxing system is used primarily to identify to Apple what a specific app’s privileges are. The requested entitlements are used to inform Apple’s decision to approve or reject an app, but the specific list of entitlements is not easily available to users, whose security is actually on the line.

Update (2017-10-25): See also: Kif Leswing.

Type-Safe User Defaults in Swift

Mike Ash:

To declare a key, write a struct conforming to the TSUD protocol. Inside, implement a single static property called defaultValue which contains the value to be returned if UserDefaults doesn't contain a value:

struct fontSize: TSUD {
    static let defaultValue = 12.0
}

This is an interesting take that uses a new type for each key and then creates the string key from the type’s name. I have been using a simpler system that looks something like this:

// register
extension MJTUserDefaults.IntDefault {
    static let cacheSize = key("CacheSize", 2000)
}

// query
MJTDefaults[.cacheSize]

I like this because it’s compact to register a bunch of keys in sequence and because putting them all into the same type works well for auto-completion.

Update (2017-10-09): Jean-David Gadina (tweet):

The solution I propose is to automate the wrapping code on runtime, using reflection. This used to be done with the Objective-C runtime. With Swift, it’s even easier through the use of the Mirror class.

Update (2017-10-14): Nicolas Bouilleaud:

#function, as per the documentation, “inside a property getter or setter it is the name of that property”. Unfortunately, that means we can’t write:

struct Prefs_ {
    var foo = TSUD<Date>()
}

because in this context, #function would be Prefs_. Using lazy, I guess, implicitely creates a closure, which is called as a getter the first time the property is accessed, and #function is foo.

Why Many Developers Still Prefer Objective-C to Swift

Paul Hudson:

Objective-C – once the rising star of the app development world – has started to become a second-class citizen in the Apple ecosystem. Yes, it might occasionally get dusted off for a slide or two at WWDC, but the majority of conference talks worldwide are in Swift, Apple is pushing Swift hard in the education space, and major language features come to Swift first.

But if you’re still using Objective-C, you’re not alone – many other developers still prefer Objective-C to Swift, and with good reasons. I got in touch with some Objective-C developers to ask what’s holding them back, whether they feel Objective-C development has become stigmatized, and more – here’s what they had to say…

[…]

Steve Troughton-Smith: Swift was absolutely catastrophic for Objective-C development; for any new APIs or features I no longer have sample code, WWDC slides, tutorials, GitHub or StackOverflow. Whatever about StackOverflow millennial jokes, but losing access to all of this context and knowledge is devastating. On the plus side, the ObjC language itself has gained a bunch of quality of life/syntactic sugar features to help it interop with Swift better, and all of those have been fantastic.

[…]

Michael Lauer: I can only dream about what could have been Objective-C if there was the same manpower behind it.

[…]

Marcel Weiher: Objective-C is OK for what it is and really needs a bullet in the head more than further development!

What’s more surprising and somewhat disturbing is how many obvious defects in the libraries and “preferred coding styles” that would have been trivial to fix without introducing a whole new language weren’t until Swift arrived – and are now attributed to Swift. It’s almost as if these improvements were held back in order to make Swift look good, though I am pretty sure that’s not how it happened.

However, the biggest negative impact will be that it will most likely prevent the development of successor that’s an actual improvement. We really have enough information to build such a beast now, and Apple ignored just about all of it.

It’s not good that people feel left out, but I’ve been pretty happy with the advancement of Swift so far. I feared that people wouldn’t embrace it, and it would be stuck in a limbo like some other former Apple technologies. People would be worried about using it because they thought Apple would drop it, and this would become a self-fulfilling prophecy. Instead, it seems like the train is going full steam ahead, and that gives us clarity. You don’t have to give up Objective-C right now if you prefer it. But time spent learning about Swift at this point will not be wasted. Swift is the future for most development. Yet I think Objective-C will remain useful for a long time to come, both because of existing code bases and because certain APIs and optimizations are more accessible from it.

Update (2017-10-06): See also: Steve Troughton-Smith, Wil Shipley, Hacker News.

When JSONDecoder Meets the Real World

Dave Lyon:

Take for example the “empty” object in JSON. You might expect that an object nested under another object would either be a complete and valid object or would be null – and this is what JSONDecoder expects as well. But in many cases an API might return an empty object (that looks like {}) and cause your JSON decoding to fail even if you’re decoding in to an Optional.

When faced with this issue recently I came up with a protocol based solution to work around this issue. I also made sure that the behavior was “opt-in” so that its possible to be flexible if there are differences between API endpoints.

[…]

Another issue that I hope doesn’t come up too often, is that APIs that have survived for a long time in the wild can sometimes have “versions” (if you’re lucky) or even potentially just have different representations for the same object based on which endpoint is requested. One way to handle this is to “smuggle” some context in to your decoding methods via the Decoder’s userInfo dictionary. Of course we would prefer to have a more structured contract for these and avoid any “Stringly Typed” interfaces, so we’ll want to leverage extensions to add a real interface to the JSONDecoder.

Previously: Swift.Codable, Swift 4: JSON With Encoder and Encodable.

Copyright © 2000–2024 Michael Tsai.