Today my new iPhone arrived. Upgrade time!

First failure - don’t back up to iCloud, it’ll take forever. Back up to your Mac. Remember what Mac it is you back up to. And enable backup encryption. Because if you don’t, it’ll forget all your health data and all your passwords, and apparently also apps that require encryption. News to me.

Before this, though, unpair the Apple Watch from the phone. Because, it turns out that this is the only way to back it up.

So by unpairing (it takes about 5 minutes) you get a backup on your phone. Then you can backup your phone to a Mac, remembering to have it an encrypted backup, and THEN you can restore your old phone on the new, and only have half the apps be gone for no good reason.

Now you’re just a confused panda, compared to the sad panda you’d be if you did it any other way.

Did I mention that the process around switching iPhones really needs improving? Apple engineers, I would expect you guys are doing this three times a day. Why is this not worked through? Let me just set up the new phone with a nod to the old phone, have all my info moved over securely, including the Apple Watch pairing and pairing with all other devices, and then have the old phone know it is now only a backup until at some point it is cleared out?

Apple Music was released today, and just like the entire internet west of Androidia, I updated my devices so I could try it out. Here are my initial impressions. They will surely be moderated with time.

Getting started was easy. That’s great. And browsing through the music catalog is very nicely designed. Unfortunately, the first tracks I browsed to were broken. Not because of something Apple did, but because the publisher didn’t pay enough attention when he ripped the CD!. Long story… I know the guy… but I wish Apple would have some algorithm in store to detect these weird anomalies.

I had heared good things about “For You”, so I fired it up. I like baroque music. That is what I want it to find. So I got the circles, and the closest match was Classical. Ok, double tap on that and Next. Then my only choice was Bach. Really?! Oh, there’s a “More artists” button (Artists? You mean composers, right?), and that got me one more: Vivaldi. But it insists I had to choose three. And there were no more baroque composers to choose from. Also no renaissance, early 16th century or even Rococco. Bah. So I chose Beethoven. I don’t plan to listen to much Beethoven. Nothing against the guy, but I wanted to listen to baroque music.

So I hit done, and for the first screen there is absolutely nothing that is classical music! Also nothing for the second screen, and by the end of the third screen there’s Brahms. Really? He’s no baroque composer. Fourth screen, nothing classical ethere either. And at the end of the fifth screen, there’s Beethoven. I guess “For You” is not for me. Apple Music has a lot of great baroque music. But it lacks discovery of this at the moment. I look forward to it being added.

I think someone at Apple said “Wouldn’t it be cool if iOS apps could run on OS X”? And I think what we get is the Macbook Air 12” (2015 model). Here is why I think so:

Apple is often very good at leaving clues about the future. The clue I find the most interesting is what Tim Cook said with the introduction of the A7 processor, and Apple has repeated many times since: “it’s really a desktop class CPU”. And with the iPad Air 2 I must admit, I’m using it much like I would a desktop - and I’ve added a keyboard for it:

Of course, with Apple you have to sort in what comments to lay weight to. The last reference I’ve found to a touchscreen Mac is from october 2014 where Craig Federighi said “We don’t think it’s the right interface, honestly, […] Mac is sort of a sit-down experience.”. Since I at the same time kept unconsiously touching my desktop screen and my laptop screen, my reactions tell me that this is no longer true.

Right now, the rumour mills are full of speculations around devices with a 12” screen, both a 12” Macbook Air and a 12” iPad Pro have been predicted. I really think these are the same device. Apple has at times made two identically sized but still different screens, but they usually don’t. The iPad version of iOS is honestly not as well adapted for its interface as the iPhone version, so I think making a 12” version of iOS that isn’t just a scale-up version, would be stretching already thinly stretched resources too much.

I also don’t think Apple would just scale up a larger interface: Apple has already shown this by giving developers an iPad simulator with a resizable width and height. Resizing would make sense if it was used for having two apps run side-by-side on iOS. It would also make sense if iOS apps were running in a window on OS X.

By going the route of a 12” touch screen display for the next Macbook Air, and adding an A-series chip such as the A8 into the Macbook in addition to the expected Intel chip, Apple could let any iOS apps run on the Mac, without emulation. It’s not like they haven’t done it before: when Apple was switching to the PowerPC I was told (by my neighbour at the time) it would be able to run both Windows (3.x) and Motorola Mac applications. We’ve also had the two OS’es in one Mac situation with Rosetta, allowing Mac OS 9 to run together with OS X.

In material costs, Tech insights estimated that the A8 processor cost $37 at the time of the iPhone 6 launch, a small extra hardware price for a spectacular integration point.

The motivation for doing this, apart from great integration opportunities, are to mac the Mac a more interesting platform. All the sudden it has everything you have on iOS! Even more important, it would instantly make the many iOS developers Mac developers!

When I began developing for iOS back in the beta days of iPhoneOS 2.0, my plan was to use it as a stepping stone to build Mac apps. I still haven’t released a single Mac app, having only made a few to help me automate my build processes. I am sure I am not the only developer in this boat, and I know of many developers that have complained about the AppKit framework missing features UIKit developers take for granted.

To add to the argument, Apple released size classes for iOS that help us, together with AutoLayout, span the range from 3.5” to 10” devices. With the Apple Watch I expect it’ll bring us down to 1,25”: could that be a key to span up to 27”? At least beginning with 12” as an incremental step would not seem unreasonable.

An argument against, of course, is that the examples of using AutoLayout and size classes to span the existing range in a manner that feels optimized for each screen size are far between. How do you design a responsive UI anyway? The web guys tell us they have been doing it for ages, yet I have not seen anything that meets my criteria above: “feels optimized for each screen size”.

The second argument against, is Android. It has also been able to be make responsive UIs for a long time, and also there I can’t think of an example that meets my criteria above. And, I’ve been able to run Android and apps based on that on my Mac for a while now, and I can’t say that I’ve really taken good use of that.

The scary part of the scenario, is of course the consequence for Mac Apps. The iOS apps would probably all be vended through the iOS App Store, with it’s 30% cut to Apple and low prices. If the Mac App Store was joined together with it, it would probably impact the pricing on Mac apps, instead of what many developers are trying for - bringing Mac style pricing over to iOS.

So that is my speculation for the 12” Macbook Air / 12” iPad Pro/Plus. I’d love to hear your thoughts, and I’m looking forward to seeing how well this matches what Apple will actually bring this spring.

Open source code is legacy, buggy code. Closed source code is often worse, having had fewer eyes inspecting it. Including it in my projects would be a really bad idea if it wasn’t for that (1) they have spent time thinking about how to solve problems I have and (2) my code is at least as buggy and is going to be legacy code in just a few hours, with few people probably ever reading it again. With these odds, it’s no wonder that 80% of my time as a developer is debugging code.

With this in mind, let’s have a look at Carthage, the new dependancy manager for Cocoa. It takes the open source projects you want to use, and compiles them into a binary framework that you can then include in your project.

Cocoapods, on the other hand, will wrap your project in a workspace where it will provide another project with all the source code for the open source stuff, and the compiled frameworks if you choose to include closed source projects.

While Carthage is a more clean approach, there is one very big drawback: when I am debugging my project, I’ll meet assembly code as soon as I start using the open source projects. As a developer in Apples ecosystem, this is of course nothing new, as you meet assembly code as soon as you hit Apples frameworks.

Is this a problem? Do I really want to debug the projects I’m importing? Aren’t they too complex and don’t I have enough work debugging my own code?

Yes, I think it’s absolutely a problem. I have identified and patched countless bugs in open source projects. Some have resulted in my patch being accepted, some have resulted in me keeping a branch with my fix so I don’t have to deal with that bug again myself until the maintainer of the project will either accept my patch, fix it themselves, or a patched fork will take over in its place.

More often, though, going through the code, following the execution path along, will tell me something about how that project expects its surroundings to be, and in doing so, shows me what I’ve done wrong when I was using it. So this is a great tool for solving my bugs. And lastly, it will show me what opinions it has of how the world should be. If I don’t share those opinions, I can either write changes that enforce my view, or use this to find an alternative that is closer to what I want.

High up on my wish list is for Apple to open source its Cocoa libraries. Then I could have the benefits listed above through my entire project. That is actually the only really good thing about Java projects: whenever I want to, I can follow the execution path all the way through the libraries.

I have learned many good practices and coding skills by reading good code while debugging. I have deep respect for Apples work, and expect there to be much good code that I can learn from. Then again, they are only people as well, and they will have written bugs. I will want to write around them, and by having the code I will save ages learning how to work either with or around that code. And I will probably submit patches - and Apple will probably reject most of them becuase I either misunderstood, wrote errors myself, or am going down a different path than what they would prefer. That’ ok. Please, Apple, set your code free.

But brining it back to Carthage, I really don’t want to close down the open source code into a compiled binary. I want the source all the way until I compile and send it to the device, and even there I want the source to see what’s going on. Only when I ship would I like it to be in binary form. And honestly, that’s only because I want it to be as efficient as possible. I’m sure I could reap big benefits of my source being available in my production code, so that I could have crashes well documented right away, instead of re-symbolicating a binary. But for now at least, compiled and compiler-optimized code outweighs these benefits.

So I’ll stick with CocoaPods, where I can see the open source code the entire while. Those are real, important benefits to me, and I can deal with project wrapping and other odd artefacts they may introduce. CocoaPods is well maintained, and they know very well what they do to my projects today, and work hard to do less to it tomorrow and the day after.

Having said that, I appreciate Carthage being there. I do like there being competition, and I’m sure having an alternative out there will improve the exchange of ideas, making both Carthage and CocoaPods even better than if either of them was alone out there.

Following up on my little SSD series, today I finally got my Seagate GoFlex thunderbolt enclosure from customs. The SSD arrived around two weeks ago, and I had already done a SuperDuper copy of my home-made Fusion drive to the SSD via USB 2.0. Three days later, I could start using it, via USB. First I preferred the extra speed from my Fusion drive, but pretty soon I took the quiet of the SSD over those extra MB/sec.

Speed-wise I was surprised to find I would get about 34 MB/sec via USB 2.0. I guess I under-estimated USB 2.0 a little bit, assuming I would get ~20 MB/sec. The Fusion drive solution would give me bursts of 114 MB/sec write and 180 MB/sec read, but over time I would often get around ~30 MB/sec. I must admit I had forgotten exactly how slow magnetic disks can be, I assumed I would get around ~80 MB/sec from it, but I was wrong. So resolving my over-estimating magnetic disk speeds and under-estimating USB 2.0 speed and enjoying the quiet, the last week was spent running of the SSD via USB. That meant that taking it out of the USB dock and into the GoFlex thunderbolt adapter took a few seconds and I could boot.

I’m sure you guessed it, as had I, but wow! Thunderbolt is fast! Even though I knew it only performed a bit more than half as quick as what the disk is capable of, starting up Photoshop was 7 seconds (vs 23 seconds before) and other apps are similarly responsive. Using Lightroom is soo much smoother. :-)

The final result was that I’m getting a pretty consistent 355 MB/sec write and 383 MB/sec read of the disk, which is better than the 330 MB/sec I was expecting, but far from the 550 MB/sec the disk can deliver. I still have found no answer to why all those enclosures won’t push the disk speed further, even Thunderbolt 1 has bandwidth to spare at this speed. But since I knew that going in, all in all I’m very happy. :-) And hopefully, this is where my SSD story ends, until I’ll transition to my next iMac in two CPU generations time.