Where technology meets something or other

Erica Sadun. iPhone. iPod touch. Macintosh. and More.


erica at ericasadun.com


  1. RSS
  2. admin
  3. valid XHTML

That UIAlertView thing: Deprecation and dinosaurs1 Comment

erica | 4:03 pm | July 22, 2014 | Development,iOS

Are you surprised at how many devs are focused on developing new iOS 7-specific applications this late into the game? iOS 7 has a 2 – 3 month ticking time bomb on it and yet every day, I encounter developers whose primary focus is getting their iOS 7 apps into shape for this autumn rather than building iOS 8 for launch this fall.

Sure iOS 7 and iOS 7 compatibility aren’t going away for a while. Even those devs aware of UIAlertView deprecation are focused on bigger deployment issues. Nearly all of them have irrational partners and bosses who insist on backwards compatibility to roughly the jurassic period. If a new iOS 7 app will work on iOS 8 that’s all they want or need. Taking advantage of iOS 8 features, well that’s for other people.

When you work on books, it’s awfully easy to get stuck in Apple headspace. Take UIAlertView. It’s been deprecated and I keep coming back to that, mostly because deprecated classes aren’t even available in Swift these days. Somehow this keeps resonating to my “It’s dead, Jim! I’m a doctor not a miracle worker” senses. I have to keep reminding myself of the day-to-day realities of the app store as it exists, not as Apple would have it. And yet when developers come to me asking how to build HUDs based on UIAlertView this late in the game, I start going UIAlertController ballistic.

The way I see it, ever since App Store started offering platform-specific upgrades, the pressure to back-support all devices all the time was gone. Unless you’re developing something new but specific to older devices (there’s a big market out there if you’re prepared to fight the tool suite, hi Chris S!), why not keep pushing forward with new releases? It’s not as if older systems can’t still do business with you. And when they upgrade, your newer versions are ready for them to download.

How much back compatibility do you think is necessary, especially if you put out regular updates?  If the world is upgrading with you, what are you gaining from supporting those 10% of users who have access to your product but may not be running the latest version of your software? What am I missing here?

I’m really curious to hear what you have to say.

I’m new to iOS. Should I learn Swift?0 Comments

erica | 3:07 pm | July 21, 2014 | Development,Swift

In a word? No. If you’re trying to pick up the fundamentals of iOS and its Cocoa Touch APIs, you’re better served at this point by learning Objective C. Swift is a very young language. It changes month by month. Swift might represent the future of iOS development but the present chugs along powered by Objective C.

When you learn Objective C, you buy in not just to iOS but to a wide and healthy ecosystem of books, videos, tutorials, discussion groups, mailing lists and so forth. Yes, you may may argue that those resources skew towards API knowledge over language knowledge — but the language they provide that knowledge in is inarguably Objective C.  You need experience with Foundation, UIKit, Quartz,  AVFoundation, and so forth. Many devs earn that expertise studying examples from GitHub and StackOverflow. In Objective C.

Swift remains immature. You’ll find yourself spending as much time fighting the compiler as learning the language. You create Swift apps line by line, adapting prior platform experience to new language limitations, often struggling with cryptic error messages ($T4 anyone? Unwrapped optional?) that reflect how young these tools are.

Sure, you may bring a lot of general knowledge and a strong computer science background, but what really matters at this point is going into development with an expectation of what you’re trying to build already on the ground. If you already know where you’re going, learning Swift will help get you there. If you’re new to iOS, there’s simply too much happening at once.

Right now many firms are searching for Swift-proficient developers. Whether this is a good idea or not is up for debate but what isn’t up for debate is what they’re really looking for:  people who already know the frameworks and who know how to put software together for iOS. The Swift skills experienced devs are picking up right now are icing on the cake, and an investment in the future.

Thanks, Fyolnish

Swift: Beta 4 very pretty1 Comment

erica | 2:21 pm | | Development,Swift

Many exciting updates in Beta 4. A few thoughts.

Jumpbar support for //MARK:. Finally, Swift has a #pragma mark equivalent

Minimum deployment enforcement. If you’ve been having fun deploying to iOS 6, the party is over.

Strides. Ranges now use stride() instead of by(). I’m still waiting for Xcode to finish downloading so I can test this, but the idea is that you use stride(from, to/through, by) instead. I need to check whether it finally does negative ranges correctly or not.

Access control. This is a biggie and has been long promised by the engineers. You can declare items as public, private, and internal to hide implementation details from client types.

Updated modifiers. Swift is losing several @-keywords, replacing them with unadorned keywords. So instead of @lazy, you have lazy, and instead of @optional you have optional.

CGFloat works right. It should wrap to the proper architectural implementation.

RIP CString. It’s now all ConstUnSafePointer<Int8> all the time. I still can’t get most of my straight C stuff ported but it looks like things are getting closer.

Safer OS X Playboxes. They’re now in sandboxes. Big hat tip to Steven Troughton-Smith on this one.

Shared Playground Data. This looks neat. You access ~/Documents/Shared\ Playground\ Data.

Icons: Fathomable and unfathomable0 Comments

erica | 3:25 pm | July 18, 2014 | Development,Various Frustrations,Xcode

Screen Shot 2014-07-18 at 3.16.03 PM

From left to right you have: File, Quick Help, Identity, Attribute, Size, Connections, Bindings, and View Effects. While it’s not as if you can’t figure the new icons out by position and general shape, I’m left a little bewildered as to the design intent for this update.

Beta: Apps and Traits, some thoughts0 Comments

erica | 11:03 am | | Development,iOS

The iOS family continues to grow. Although iOS targets are not nearly as splintered as Android’s multitude, iOS apps must adapt interfaces to numerous configurations for universal deployment. Routines specific to iPads or iPhones, to landscape or portrait orientation, and to retina or non-retina screens have transformed many iOS apps into a tangle of special-purpose code.

To push back, iOS 6 introduced Auto Layout, a descriptive system for interface design. Auto Layout enabled developers to use rule-based view placement that automatically adjusts to screen dimensions and orientation.

Now iOS 8 adds the notion of adaptive deployment. New classes and protocols enable apps to retrieve the specifics of the current runtime environment. This enables them to adapt not only to hardware limitations but also to whatever screen space has been allocated to their presentations. A truly adaptive app gracefully responds with a well designed and engaging interface, ready for the user at any size.

A iOS 8 trait collection describes a single point in deployment space. This space represents the range of possible conditions an interface might encounter in the real world. By making these traits concrete, Apple enters into a somewhat implicit contract with the developer – these are the types and ranges of flexibility you must design for.

Even if Apple introduces multi-windowing, you only have to worry about “compact” and “regular” interface sizes under the current system. There’s a (vague and legally unenforcable) guarantee that for at least the next year Apple will not add some “Ultra Compact” game-changer where you suddenly have to worry about designing forms for 100-pixel destinations. And, if Apple does introduce that windowing, the traitCollectionDidChange callback means you can switch your tablet presentations to phone ones for side-by-side execution and then back again.

No matter what kind of apps you design, a tension always exists between pixel-perfect control and adaptability. An interface that looks stunning on a 4″ iPhone may look cramped on a 3.5″ screen and sparse on a tablet. This has led some developers to build what is essentially multiple codebases under a single app umbrella.

With trait collections and standardized callbacks, iOS 8 is attempting to bring sanity back to those apps. So long as the presentation specifics don’t get too ridiculous, Auto Layout and trait-driven assets should be able to handle those specifics both at launch time and during run time.

Will Apple introduce a 3x display resolution? I think it unlikely but if they do, the technology is already in-place to handle that trait collection with a 3.0 display scale. Will Apple add a new geometry to the phone family? That’s a rumor that seems to have more appeal — but Auto Layout is ready for that, and the compact-regular layout traits will support any baby-dolphin-sized phablet that might hit the market. Will iOS 8 support multi-app display? The technology to support it is ready for developers if they take advantage of those features.

I admit that some of Apple’s design choices for trait collections baffle me. For example, how is it that a 480-point height is “regular” and a 586-point width is “compact”? But despite that, I find it comforting to  receive a concrete set of interface expectations via the trait API.

What do you think? Please do let me know.

Beta: Auto Layout Constraint Activation2 Comments

erica | 1:58 pm | July 11, 2014 | Development,iOS

I’m pretty excited about the new active constraint property. To date, a lot of my work involves adding and removing constraints. Now with activateConstraints: and deactivateConstraints: you can enable and disable constraint groups all at once. I can see this being used in a variety of ways:

I’m not sure if this is animatable so I have to test that bit, but I’m really hoping it is.

One final note: the two activator/deactivator methods are documented to be more efficient than accessing constraints one-by-one.

UPDATE: WHOA! Self-installing constraints! Finally!

UIView *v = [UIView new];

v.autoLayoutEnabled = YES;

[self.view addSubview:v];

NSLayoutConstraint *c = [NSLayoutConstraint constraintWithItem:v attribute:NSLayoutAttributeCenterX relatedBy:NSLayoutRelationEqual toItem:self.view attribute:NSLayoutAttributeCenterX multiplier:1 constant:0];

NSLog(@”%@”, self.view.constraints);

c.active = YES;

NSLog(@”%@”, self.view.constraints);

2014-07-11 16:44:09.138 Hello World[18020:1138706] (


2014-07-11 16:44:09.141 Hello World[18020:1138706] (

    “<NSLayoutConstraint:0x7fed2d809090 UIView:0x7fed2d9449b0.centerX == UIView:0x7fed2d93da70.centerX>”



Beta: Coordinate spaces0 Comments

erica | 1:48 pm | | Development,iOS

New in beta 3, coordinate spaces are a UIScreen property. There’s a UICoordinateSpace protocol for UIViews and APIs to support point conversion, presumably for split-screen app development.


Added UIScreen.coordinateSpace


Added UICoordinateSpace
Added UICoordinateSpace.bounds
Added -[UICoordinateSpace convertPoint:fromCoordinateSpace:]
-[UICoordinateSpace convertPoint:toCoordinateSpace:]
Added -[UICoordinateSpace convertRect:fromCoordinateSpace:]
Added -[UICoordinateSpace convertRect:toCoordinateSpace:]


Swift: Adding multiple-index array access0 Comments

erica | 12:34 pm | July 10, 2014 | Development,Swift

This morning, #swift-lang buzzed about multiple subscripts. “zOMG, you can have subscripts take more than one argument?” Why yes, yes you can. It’s a neat Swift trick, but a (pardon me) a tricky one.

For example, you might create an array and want to index it with foo[3, 5] or foo[7, 9]. Turns out that the general case is slightly trickier than I anticipated. The following demonstrates the desired indexing behavior.

let foo = [1, 2, 3, 4, 5, 6, 7]
println(foo[2]) // prints 3
println(foo[2, 4]) // prints [3, 5]
println(foo[2, 4, 1]) // prints [3, 5, 2]
println(foo[2, 4, 1, 5]) // prints [3, 5, 2, 6]

However, you don’t get this behavior out of the box.

Screen Shot 2014-07-10 at 11.47.55

Backtracking a little, you can easily build a custom subscript when you know a priori the number of elements you’re aiming for. For example, this extension returns two index items at a time. This is easy to implement and Swift can easily use parameter matching to figure out the overloaded results you’re aiming for.

// Two at a time
extension Array {
    typealias ArrayType = Element
    subscript(i1: Int, i2:Int) -> [ArrayType] {
        return [self[i1], self[i2]]

It’s harder to extend this behavior for an arbitrary number of arguments. Specifically, you must take care with variadic arguments. The following approach won’t work.

subscript(i1: Int, i2:Int...)

Use that approach and you end up with infinite loops. That’s because Swift cannot distinguish this parameter declaration from an override of the standard single-item indexing. Variadic parameters accept zero or more values of a specified type, so  [2], [2, 4], [2, 4, 6], and [2,4, 6, 8] all match this declaration.

(Int, Int…) is virtually identical to (Int) at runtime, so Swift chooses this override to the original implementation for single-parameter lookups. That’s where the infinite loops come from. To make this work, you need a signature that won’t confuse swift. The proper solution uses two non-variadic arguments followed by a third variadic one, creating a “use this implementation for two or more parameters” scenario.

The following extension provides a final working solution. When you provide at least two subscript arguments, Swift knows to use this subscripting implementation.

extension Array {
    typealias ArrayType = Element
    subscript(i1: Int, i2: Int, rest: Int...) ->  [ArrayType] {
        var result = [self[i1], self[i2]]
            for index in rest {
                result += self[index]
            return result


Swift: Coping with bad enum typedefs0 Comments

erica | 8:51 pm | July 8, 2014 | Development,Swift

Earlier this evening, a member of #iphonedev on Freenode needed to use the following function:

func rangeEnclosingPosition(_ position: UITextPosition!,
            withGranularity granularity: UITextGranularity,
                inDirection direction: UITextDirection) -> UITextRange!

The docs say that UITextDirection “can be of type UITextStorageDirection or UITextLayoutDirection.” but when you look this all up, you get:

enum UITextStorageDirection : Int {
    case Forward
    case Backward

enum UITextLayoutDirection : Int {
    case Right
    case Left
    case Up
    case Down

typealias UITextDirection = Int

As one member of the #swift-lang room put it, “‘My fault or Swift’s fault’ is a pretty frustrating experience.”

What to do? Kevin B was able to suggest an immediate workaround by using UITextStorageDirection.Forward.toRaw(), and encouraged filing a radar.

Bigger lesson, especially taking yesterday’s language updates into account: Don’t write production code in a beta language, and make copious notes where you used work-arounds so you can re-address them later.

Product FAQ: Storing custom colors in Folderol and Color App0 Comments

erica | 4:58 pm | | Admin,FAQ,Software

If you’re using Color App or Folderol and want to store custom colors, open the color palette. Drag down the small dot at the bottom of the palette to reveal the customizable color wells. From there you can drag colors into any of the slots or  click them to load an already-saved color.

Screen Shot 2014-07-08 at 4.41.03 PM

« Older Posts

wordpress | sheepdip design by mahud © 2007