Subjective-C

Opinions about Cocoa(Touch), and general programming.

[subjective-c]

Fake @autoclosure for Logging in Objective–C(++)

This may seem obvious to you, but it definitely wasn’t to me until just a couple of minutes ago: Swift doesn’t have macros, and one of its mitigation techniques to replicate some of the stuff one could do with them is the @autoclosure keyword.

This allows macro like behavior, in that you can write an expression, which is automatically wrapped into a closure, and passed into the function.

Need an example? Look no further than the XCTAssert() function, which allows you to write XCTAssert(boolReturningFunction()) instead of XCTAssert({return boolReturningFunction}).

Now suppose you’re writing a logging facility that supports different log levels, and doesn’t generate log messages unless the severity of an incident passes some threshold — after all: especially debug–level messages can be very detailed, and somewhat costly to create (e.g. converting a large array of objects with complex structure to a string takes time).

Many people deal with this by wrapping NSLog in a macro that’s defined as nothing in release builds, and something in debug builds. That works, but it means if you run into a hard–to reproduce error situation on a release build, you’re hosed: in order to get more logging you need to recompile your app, and then hope you can reproduce the issue.

A significantly more powerful way is using something like LibComponentLogging, that not only allows you to have different logging levels for different components of your systems, and different logging backends (to the console, to a database, perhaps to a server, …), but also changing them at run time.

But what if you want different log–levels for different backends, that incurs low overhead without exposing log levels as global variables?

An @autoclosure message: () -> String parameter would be how I’d tackle that in Swift. True, that incurs the cost of creating a closure, but that’s small in comparison to the string conversion.

But in Objective–C?

Well, how about this logging function:

NS_ASSUME_NONNULL_BEGIN FOUNDATION_EXTERN void Log(log_level level, const char *file, NSUInteger line, NSString *(^message)(void)); NS_ASSUME_NONNULL_END

Doesn’t look very pleasant to use, does it? You’d probably prefer using something closer to this: Warn(@"foo made a booboo: %@", someObject);.

Well you can combine those two, defining Warn() like this:

#define Warn(format, ...) Log(log_level_warn, __FILE__, __LINE__, ^{ \ return ([NSString stringWithFormat:format, ##__VA_ARGS__]); \ })

And there you have it: a fake @autoclosure for Objective–C(++) logging.

[subjective-c]

Swift

It’s been a while since my last post, and a lot has changed. One of the more obvious changes to the universe I work in, is the introduction of this programming language called Swift, at WWDC 2014. So more than a year ago. Enough time to reflect on this ever–changing language, that I am unsure I am up–to–date with: I haven’t thoroughly looked into its 2.1 changes, yet. iA writer says that this post weighs in at almost 1.800 words, so you might want to stop after the first half, because a) the rest is just me bitching, and b) it can’t get much better than an excerpt from an Asterix movie.

There’s a lot of enthusiasm about this language. Initially, I was quite enthusiastic myself, and worked through the entirety of “The Swift Programming Language” by the mid of the week it came out. Just as other programming languages I looked into, this one has influenced the way I write Objective–C(++). And there are a couple of features I would love to see in Objective–C(++).

From that last paragraph, you can probably see that I’m nowhere near ditching the language that inspired the name of this blog. For me, using Swift in production is still an absolute no–go. And that has lead to me writing only little code in it.

Why It Is a No–Go For Me

One of the changes since my last article, is that I have a new job in which I contribute to a third party framework, and when you hear “framework”, “Swift”, and “3rd party” in one sentence, you can be sure that the rest of the sentence will probably discuss some problem. That isn’t to say that you cannot use that framework from Swift! Quite to the contrary, the team has put in a lot of effort to make the framework have top notch Swift support:

All public facing APIs have been audited for, and properly annotated with nullability and generics.

Any new APIs have been designed with Swift in mind, so that using them from that language feels natural.

The framework itself does not contain a single line of Swift code.

You read that last item right. Swift’s binary compatibility story is best described by the Swift team itself:

While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.

(Source: https://developer.apple.com/swift/blog/?id=2)

Yes, that is from the 2nd ever post on the official Swift Blog — so it’s one–and–a–half years, and one major language version old. It is also still completely accurate, and will — for the foreseeable future — remain this way.

So if you’re in the business of licensing frameworks to customers, and your framework contains Swift, you have to offer your customers one version of your framework per public Xcode release — and yes: betas are public, in this regard. Staffing up your customer support department is probably a good idea too, because that’s a lot of versions to choose from, and you can bet on having at least one customer have at least one developer in the team that uses your product be on a different Xcode version than the rest. Or maybe the CI server wasn’t updated in time, or some such similar bullshit no-one ever should have to put up with in the 21st century, ever.

Now, that’s the customer–facing side, and from where I stand, that doesn’t exactly sound like sunshine, and rainbows. <snark>But clearly, the developer side is much better, right?</snark> Casting aside SourceKit quitting unexpectedly (1. by week 2, it’s no longer unexpected, and 2. it’s gotten much better, lately), you will have to fix bugs. In your Swift code. And that’s where the fun begins because this is an evolving language (not bad, per se), that changes from Xcode beta to Xcode beta (well…), in ways that are seldom backwards compatible on the source code level (ugh, fuck).

Trying to support that would be equivalent to find permit A38. (Before following that link: I felt the sudden urge to binge–watch all the Asterix movies right now, so be warned…) So, what you could do, instead, would be to state you support the latest stable Xcode, and its latest beta, so that you only ever have to have 2 branches to fix bugs on in incompatible versions of the language — that’s more manageable, but still quite a bit of overhead.

Still reading? Great! So with that, I think I have thoroughly established why “using Swift in production” is as much of an option to me, as going to the moon is.

The Bigger Picture

Okay, but how about using Swift in production when what you’re building is an app? Disclaimer: I don’t. So what do I know.

What I do know is what would piss me off:

Compile Times They’ve gotten better, but they are still bad for every project of non–trivial size.

Compiler Diagnostics They have gotten drastically better since beta 1 of Xcode 6; they are still not good. Generics, and overloading can make them very misleading.

Xcode Editor Bugs Objective–C suffers here as well, but from my very subjective perspective it’s probably about an order of magnitude worse in Swift.

No C++ Interoperability To be honest, this isn’t something I run into a lot, but you miss it once you need it.

Impedance Mismatch This holds especially for older APIs, but anything that uses the dynamic nature of Objective–C feels weird in Swift. Sometimes, like when you set/hook up your UI in code, this leads to a loss in safety, because where there is only a StringLiteralConvertible and no @selector, there is no -Wselector. So your typo goes unchecked, and you end up wondering why pressing that button doesn’t do any good. (Interface Builder would save your bacon here, and warn you — as it always has.) At other times it just leads to confusion.

Behavioral Differences Between Playground and App/Script This is almost ironic: This feature is an indispensable tool for learning the Swift language, its (new) features, and experimenting with new APIs, without having to go through the (see first item: now even slower) edit–compile–run cycle. But it is really annoying when you’re trying to wrap your head around some aspect of the language, and you figure out that the reason why you’ve been violently banging your head against the wall for the last couple of hours isn’t that you misunderstood something. But instead, the exact code that does not compile in the playground works flawlessly when you throw it in — say — a Swift CLI script.

If you think this last item was a little long for a list, then allow me to take on the elephant in the room: From early June to mid September, using Swift in production means having to choose between a rock and a hard place.

The rock During WWDC’s State of the Union, branch your codebase, and stay up to date with the evolution of the new major version of Swift on your development branch(es). This implies fixing every bug twice during the period where you should adopt new OS/framework features, and adapt to those changes — oh, and also you probably wanted to find a sensible time to take vacation while the sun’s up longer, too, right? (In addition, there will be bugs in the new tools, but that affects any development, so listing it here would be unfair.)

The hard place You don’t use any of the new language features until the golden master of Xcode version++. You miss out on reporting bugs against the language, the compiler, and the rest of the toolchain at a time where they are most likely to be fixed quickly — in turn, making it less likely that these bugs are actually fixed at the time you rely on Xcode to ship your product. Granted: The more severe the bug, the less likely it is that no–one else will report it. But time is a finite resource, the deadline for shipping a new major version of Xcode is tight, and so teams — especially within Apple — have to prioritize. Radically. Also, in this scenario you have to migrate your code at a time when it runs on at least 1 completely new device (probably there are 2, maybe even more), that you did not have available for testing during development. Device specific bugs/regressions are a reality of life, only their importance/magnitude varies. (I don’t use, or even own an iPhone 6+, but apparently quite a few apps still don’t support it properly. It has been on sale for a year.) So when the bugs from your app running on previously untested OS/device combinations come in, you have to set aside time to migrate your codebase over. If you are working in a software consultancy/agency (at least in Germany), this is also a very busy time of the year anyways: at the end of the fiscal year, all those unused budgets need to be spent — otherwise they might get cut in the next year (this factoid would be downright funny if it wasn’t so sad…but I digress). That means more clients are looking for someone to build them an app or a new feature for their existing one. And so what looks like a more conservative, and thoughtful approach initially, turns out to be far from great, too.

So yeah, not all roses.

This has lead me to believe that if things keep changing the way they did over the last year (especially this summer), using Swift in production is just not very attractive.

It offers a couple of things that I’d love to have available: Even with their bugs, playgrounds, and rich comments would be awesome for documentation alone! The guard statement, and deferred initialization of constants (i.e. let foo; if predicate { foo = a; } else { foo = b; }), are absolutely great! And if you ever had the pleasure to work with e.g. libcrypto, the combination of guard, and defer will make you cry tears of joy — this goes double, if your workplace shuns goto statements.

But no binary compatibility to the point where even building a framework, and your app separately can cause problems? If that sounds promising to you, you might also enjoy a piece of this arsenic cake…

[ikarost]

[thatlowvice]

Seeing shit like this is why i love travelling/flying

[stalethings]

<3

[subjective-c]

Cue one of my favorite Einstein quotes… /via @incalidname

[subjective-c]

Caching for Images from Secondary Bundles

As a slight departure from the usual rants, (fear not, as I have a new one in the pipeline!) today I’m posting a little something you might actually find helpful!

Ever worked with resources from multiple bundles on iOS?

If so, you’re probably familiar with the absence of the following method:

/** Returns the image object associated with the specified filename from the specified bundle. This method looks in the system caches for an image object with the specified name and returns that object if it exists. If a matching image object is not already in the cache, this method loads the image data from the specified file, caches it, and then returns the resulting object. Bla, bla, bla, you know the rest — if not, look in the docs for `UIImage`. @param name The name of the file. If this is the first time the image is being loaded, the method looks for an image with this name in the specified bundle. @param bundle The bundle from which to load the image. */ + (UIImage *)imageNamed:(NSString *)name inBundle:(NSBundle *)bundle;

Well, I had a couple of spare hours so I hacked up a little something you can find it over at Github.

It’s published under the 2-clause BSD license, so you can basically do whatever you want with it — as long as you give attribution.

[subjective-c]

vanilla-js.com is mature, battle proven, and performant! /via [Joris Kluivers](http://joris.kluivers.nl/blog/2012/08/27/vanilla-js/)

[stalethings]

Interesting 30 minutes that you really should invest

[subjective-c]

Catching up on my “reading”, I also found this video via stalethings, a photographing bike-nerd, and software-architect.

I couldn’t agree more: It’s great to see, and understand the “why”s behind many of the things that sucked about OAuth 1! In addition, it’s reassuring (and depressing at the same time) to learn more about the gaping holes in OAuth 2 by one of the major people involved with it.

[subjective-c]

Paging vs. Scrolling

Now that I’m on vacation, (yay!) I finally managed to read up on several blogs I didn‘t visit in a while. And like every time I catch up on my reading, I found interesting articles on Lukas Mathis’s excellent blog called “Ignore the Code”.

As you may have guessed from the title of this post, he wrote a few posts about the never-ending debate of paging versus scrolling.

What’s not necessarily obvious is that I disagree with his general conclusion:

Pagination gets out of the way. Read a page. Push a button. Read the next page. Repeat. No needless interference with the actual text being read, no unnecessary interactions that could pull the reader out of the book’s world. — Scrolling vs. Pagination, Lukas Mathis

No, it doesn’t: On electronic devices, pagination interferes heavily because you have almost no control at all over how things are rendered!

You Don’t Know How to Break Paragraphs in Advance

This starts with the glaringly obvious things, such as a phone, and a tablet sporting vastly different screen sizes. (Because you probably don’t want your work published on iOS exclusively, feel free to add a gazillion of screen sizes, and display technologies for Android, Windows Phone, and all of the traditional—aka “Desktop”—operating systems.)

It continues with the not-quite-so-obvious fact, that each and any of the Desknot-devices features at least two screen sizes itself: one for portrait, and one for landscape orientations. (IIRC Windows RT apps have even more, because they feature this split window mode, that I’ve forgotten the name of, and can’t find right now.)

So what you’ll end up with, when your product is a book, are paragraphs that get cut into pieces at the page border, causing people to needlessly page hence and forth, when the topic at hand is not a trivial one.

This is not a genuine problem of electronic media—mind you: We’ve been trained to put up with this limitation in text-books for as long as there have been editions in print, and even well before Gutenberg invented moveable type. Whenever the choice of typeface, dimensions of medium, or even only the typographer changed, the breaking of lines, and paragraphs on typographical boundaries changed.

Maybe it’s because I get distracted easily, but short of a herd of elephants passing by my desk, there is very little I find more interfering with my flow of reading, than having to turn pages in the middle of a sentence.

Is scrolling ideal?

Of course not!

For all the reasons Lukas mentions, it is distracting labor. But with smart, paragraph-based scrolling, my hypothesis is, (and I’d bet a “Frachter” of Astra Rotlicht on that!) it is possible to measurably improve interacting with long form text over pagination. (Where by “measurably improve” I mean: reading comprehension tests with a significant sample of people, and texts show higher success rates per reading time for a system with smart scrolling, than for an arbitrarily paginated system when reading texts on comparably complex topics.)

If someone conducted such an experiment, proving my hypothesis wrong, I’d still put money on that such a test shows that there is a significant group, for which my original assumption holds.

[subjective-c]

2012 is nearing its end, and an embarrassingly large number of people **still** consider Vim an adequate tool for software development—no wonder we don’t have hoverboards yet! (Well that, and that we don’t know an awful lot about gravity…)

[subjective-c]

Objective-C Subscripts

Because what is about to follow has grown to be a somewhat long-form rant, here’s the **tl;dr**: > I do know many APIs […] that are designed for brevity, which is irrelevant in an environment with good autocomplete. That quote is a marginal note from Bret Victors article [“Learnable Programming”](http://worrydream.com/LearnableProgramming/), which — if you haven’t already — you should totally read! (Go ahead! I’ll wait, I promise.) Objective-C subscripts are such an API that’s designed for brevity, and in the many words that follow, I’ll try to explain why that makes them _syntactic saccharin_ — instead of syntactic sugar. ## The newest additions to the Objective-C language With OS X 10.8/iOS 6.0 (and the accompanying versions of the developer tools) Apple introduced a couple of new features to the Objective-C language: Object literals for arrays, dictionaries, and numbers, as well as subscripts for collections. Just like the Objective-C 2.0 dot notation, these features are mostly a little syntactic sugar, that is directly translated into method calls, with some additional type inference from the compiler for (evaluated) number literals, and two new methods to supplant subscripts. Although the object literals unfortunately don’t translate into compile-time constants, (as do string literals) I consider them extremely useful additions to the language: The “@” has always been a beacon light that signals “the following only makes sense in the context of Objective-C”, and they are _really_ concise. On the matter of subscripts, though, I have a **vastly** different opinion! ## What are subscripts? Before I go into any details _why_ I think they’re a **terrible** idea, I’ll just put up an example of what subscripts are. Subscripts allow you to write the second line of the following example: NSArray *abc = @[@"a", @"b", @"c"]; NSLog(@"Found object %@", abc[1]); As you can see, subscripts provide an alternate notation for accessing the elements within somehow ordered collections — in this case, an NSArray. The expression `abc[1]` is translated into `[abc objectAtIndexedSubscript:1]` by the latest versions of the Clang Objective-C frontend, and which is [equivalent to `[abc objectAtIndex:1]`](http://mikeash.com/pyblog/friday-qa-2012-06-22-objective-c-literals.html#comment-c4ce71c3d04c25f8f40c2b5c5e130a29). At first sight, this appears pretty fathomable — because it is an absolutely contrived example. In the real world, the definition and usage of “abc” would be separated by several, maybe _dozens_ lines of code, and “1” would be a variable, too. This wouldn’t be _that_ much of a problem, if Objective-C wasn’t a bastard language*: In contrast to C++, Objective-C is a _true_ (albeit small) _superset_ of the C programming language. Read “everything that is valid in (ANSI) C is valid in Objective-C as well”, i.e. you can (and when optimizing your code for performance _will_) freely mix and match pure C and Objective-C. (* And I mean that with the utmost respect — I’m a pretty big fan of it! Why else would I add to the number of blogs on it?) This heritage, however, bears the problem that C doesn’t know _anything_ about objects: An Objective-C instance is actually just a pointer to a struct with a certain layout. We call this type `id`, and what transforms what is essentially a `void *` into something special, is mostly a convention put forward by the runtime. And therein lies the problem: C types are not objects, and while it is valid (and at times useful) to store objects in plain C arrays, C arrays certainly cannot receive messages! (Unless the first entry was a `Class`…) So when you read the line someArray[a]… you don’t know if someArray can receive messages or not. What’s even worse: The overflow-behavior differs wildly, depending on whether we have a C array or an NSArray! C is known for many things but memory safety isn’t one of them, so an access on an index that exceeds the bounds of the array can result in just about anything, whereas NSArray will help you identifying such programmer errors by raising an exception. NSDictionary subscripts further complect the whole situation: now I can access _any_ subscript, as long as I use an object as the key, (and as long as that key is different from `nil`, of course) — the result will just be `nil` if there was no entry for that key — so I have a **third** behavior for what appears to be the **same** line of code. Thanks for the piecewise introduction of operator overloading into the language — **not!** ## Operator overloading — when a + b ≠ b + a I’m going to be keep it brief here, but I definitely could (and probably _will_ at some point) write a whole post about why operator overloading is the pure, distilled evil. In C++, Objective-C subscripts would be exactly this: id NSArray::operator[] (NSUInteger); id NSDictionary::operator[] (id); Up until now, the operator `[]` has — or used to have — the following properties: - O(1) access to the left operand. - 0 is a _valid_ right operand. - 0 (or `NULL`) is an _invalid_ left operand. - The expression `type-pointer operator offset` is _generally_ read-write — unless explicitly specified otherwise, which then yields a compiler error in case of violation. - No memory safety whatsoever. Access is non-atomic but race-conditions are unlikely to strike, because the access is so fast. (**Update** As [Graham Lee pointed out](http://twitter.com/secboffin/status/307062248625561600), `NULL` **is** a valid left operand — as long as the right operand isn’t 0: In that case your program goes belly up, because you are trying to dereference `NULL`.) Compare this to the subscripting operator that goes by the _same symbol_: - [O(1) to O(log N) access](http://ridiculousfish.com/blog/posts/array.html) to the left operand if it’s an NSArray, O(1) to O(N) if it’s an NSDictionary. - 0 is an _invalid_ right-operand, if the left operand is an NSDictionary. It is _valid_ if we’re subscripting an NSArray. - 0 is a _valid_ left operand. Always. - The expression `collection operator operand` is _generally_ read-only — unless you have a mutable instance, (which is the **uncommon** case) and violation yields a runtime exception. - Accesses will not overflow existing memory. Because access is slower but equally reentrant as in C (read: not at all!), the probability of running into inconsistent states without external locking is much higher. Access behavior for invalid “keys” is vastly different: NSArray will throw for accesses that exceed the bounds, while NSDictionary allows everything except 0 as the key. So our lovely simple operator, that used to be syntactical sugar for `*(address + offset * sizeof(type))` has grown into three varieties which are incompatible with one another in at least one property! In essence, object subscripts exchange _clarity_, and _consistency_ for the sake of _brevity_ — and this is a **shit sandwich**: 1. A good API is discoverable, predictable, and consistent. Object subscripts are neither. 2. Brevity was an important feature when we used to define functions with a piece of chalk on a blackboard. On a computer, however, we have auto completion to assist us in writing. This allows our _bodies_ (or hands in particular) to follow our _minds_ more closely — pretty much regardless of how _long_ our individual commands are. --- ### Appendix I have recently stumbled upon the following line of code: NSMutableArray *objects = @[].mutableCopy; **What! The! Fuck!** What’s wrong with `[NSMutableArray new]`, or `[NSMutableArray array]`? Is saving 4-6 (in words **four to six**) characters really worth introducing something this _ugly_ into a codebase? Lines like this make me think about whether I should refrain from using collection literals, and dot-notation although I’m actually quite fond of them…

[subjective-c]

This is my blog!

There are many like it, but this one is mine! If you’ve thought that “Yet another blog on (iOS/Mac) programming, is _just_ what the world needs!”, then maybe you’ll enjoy this one. For me personally, it’s the thing I’ll use whenever [140 characters](https://twitter.com/__block) just aren’t enough — and with Objective-C, those occasions are not _that_ uncommon — to publish my thoughts for peer review. I’m excited to see if/how that will catch on!