July 7, 2016

iOS10 Public Beta

The public beta for iOS10 has begun - grab your downloads here. Of course, you should read the FAQ, and bear in mind that this is beta software. In other words, not something you should install on a device that you can’t afford to live without if things go wrong.

Also, you won’t be able to leave reviews on the AppStore (doing so is unfair to developers anyway, as they haven’t had the chance to update apps for iOS10 yet).

That said, however, I’ve been running the second developer beta (more or less exactly the same as the first public beta) on all my devices and have had few problems so far. Battery drain is higher than you might be used to, because the OS is doing more logging in the background, and hasn’t been fully optimised yet. But all my apps seem to work with one or two minor exceptions, and I’ve had no crashes to springboard (where the screen blacks out, shows and Apple logo, and returns you to the lock screen).

The public beta for macOS Sierra will follow later this week - I’ve also been running the developer beta on my personal Mac and it too has been very stable.

apple ios
February 25, 2016

Here’s my daughter’s 500 Words entry.

The Tame and the Wild.

Far, far, away through valleys deep and mountains cold, lived a strong and powerful wolf. In a village there was also a dog that longed to be free. One night there was a terrible storm that shattered the dog’s home. The dog barked and a child cried. The dog decided to escape to explore the valley. He was enjoying his freedom so much that he forgot where he was. Suddenly he felt all alone. After days of climbing up an enormous mountain he came across a cave. He was sniffing outside entrance when he realised there was a dark shape coming towards him as if it was ready to pounce. He became scared, his fur bristled outwards. The shape came closer and into the light. He then saw that it was not a monster. It was a harmless young wolf, about the same age as he was. The wolf sniffed the dog and made a soft whining noises. After a while the dog realised that the wolf wanted to be friends. In a language only known to animals, the wolf said, My name is Swirl, and I live in this valleyPA with a pack of wolves that are my family. What are you doing in these parts”? I have got lost, and am all alone” said the dog. Swirl replied Don’t worry, you can play with me. What’s your name”? I’m called Buster”, explained the dog. Well Buster, why don’t you come with me. We can play a game of chase.”

They ran through the trees, until the moon rose, casting great shadows over the forest. Then there was a call, from Swirl’s pack. Swirl said, Come on, meet family. I’m hungry and there’s sure to be something to eat.” Buster woke one morning, some days later, with a fully tummy, feeling safe and thinking to himself How wonderful it is to be with a pack of wolves”. But, he knew that he would need to go home soon because his beloved owners would miss him. As usual, the pack had a breakfast of wild rabbit and goat. Then the pack set out on a long journey away from the mountains. They knew Buster needed to go home. They came across a rebuilt log-cabin. On the front door there was a poster with Buster’s picture on it saying Missing” across the top. Buster knew he was home. For a while, Buster was delighted to be back. But then, at night time, he sometimes heard the wolves calling from far away. He started to howl in reply. He longed to be back in the wild, free again. His owners could see that he was full of sorrow. So, with a heavy heart, they took him back to be with his new wolf family. From then on, Buster spent the summer with his wolf family, and the winter with his human family. He felt lucky to be able to live in both the tame and the wild.

Connie, age 7

Proud dad :)

February 12, 2016

Sparkle updated vulnerability: What you need to know!

Third-party update service Sparkle, combined with insecure network protocols and parsing, leaves some OS X apps open to person-in-the-middle exploits. A vulnerability has been discovered in an open-source framework that many developers have been using to provide app update services for the Mac.

I’ve always worried that one day a vulnerability in Sparkle would be uncovered and that it would become a malware attack vector.

Well, a vulnerability has been uncovered, but as yet there’s nothing exploiting it (that we know of).

Here, for once, is a reason to actually stick with Mac App Store apps instead of buying direct from developers.

February 6, 2016

Fury road: Error 53’ is more a feature than a bug

Some iPhones have experienced an error that can lock the phone so cry Havoc!”, and let slip the dogs of war! For war” read: Rush some hyperbolic claptrap to print and try to rake in some easy hits.”

The Macalope has, as ever, the most cutting and succinct summary of the whole Error-53 debacle.

February 5, 2016

I’m Done with MacBooks

Last week I was on the road for five days straight. I brought along my MacBook Pro because, knowing that I would be away from my desk for so long, I anticipated needing to do some actual design work at some point.

I’m in almost complete agreement. I still find it useful to setup and work in a variety of locations, but that location usually involves a desk, because that’s the most comfortable way to use a laptop’ for an extended amount of time.

For my real work, I use dual widescreen monitors. I can work on just a laptop screen, but there’s no pretending I’m as productive as I am with room to spread out on multiple monitors.

February 3, 2016

No Realm

We’ve taken the decision to take Realm out of our project. It wasn’t an easy decision, considering the team had spent several weeks integrating it recently, but I believe it’s the right move.

Hopefully this post will give you an idea of why we made that decision and perhaps prevent you from repeating our costly mistake.

The Realm team have certainly built a powerful and easy to use technology, and this post isn’t intended as a criticism of what they have produced. Also, I haven’t been personally involved with implementing the Realm integration, so what I know is what I have gleaned through conversations with my colleagues.

Realm sells itself (well, rather, gives itself away) as a fast, reliable and easy to use replacement for CoreData or SQLite. It’s certainly more database like than CoreData, and it’s more of an object persistence framework than a straight SQLite database.

That’s the good bit. There are however, some significant downsides you should be aware of before committing to using Realm in your project.

Poor documentation

The team I work with have constantly complained about the quality of the documentation. Often, for anything other than basic usage, you will find yourself searching StackOverflow and Google a lot.

Inaccurate error messages

Almost worse than poor documentation are the inaccurate and misleading error messages. Several times, my colleagues have spent hours chasing down mysterious crashes because the error messages Realm provided were pointing them in the wrong direction.

No support for threading via GCD

The Realm documentation certainly claims that Realm works across threads, although I think some of the same caveats as when using CoreData apply - no passing Realm objects between threads, for instance. However this isn’t the experience that my team have had. I don’t have specific details to share, other than there was talk of potentially having to do everything on the main thread’ at one point, to avoid a serious application crash.

Requires subclassing the RLMObject class

Your Realm objects have to be a subclass of RLMObject. This is a biggie, and it’s not something that’s unique to Realm by any means - CoreData also enforces this limitation, requiring you to subclass NSManagedObject.

The problem with this approach becomes apparent when you understand that our app also makes heavy use of Mantle which is a very convenient way to integrate your app model layer with a web API. Unfortunately, Mantle also requires that your objects subclass MTLModel. Objective-C (or Swift) doesn’t support multiple inheritance. In order to integrate Realm with Mantle you’re looking at writing some kind of adapter layer to convert from one to the other. All of a sudden all these promises of quick’ and easy’ are starting to look pretty hollow.

Aside: One of the key technologies in iOS is NSCoding - a class conforming to this knows how to archive and unarchive itself when passed to NSKeyedArchiver. Being a protocol, it doesn’t require that your object is a particular kind of class. I think this is the ideal approach, and with the move to Protocol Oriented Programming, I hope we’ll see more technologies implemented as protocols - allowing you to compose the functionality you desire from a shopping list of capabilities.

No Cascading Deletes

This seems like a major omission, and it was really the straw that broke the camel’s back for our team.

Our use case for Realm was to rapidly and repeatedly store and restore data as the user completes a complex form. We want to prevent any chance of data loss, so we are archiving our object graph to Realm after each user interaction. Some of these interaction can invalidate portions of the object graph, so we were suddenly faced with a growing problem of wasted disk space as Realm didn’t automatically remove objects that were no longer needed.

The team were faced with solving the problem of manually maintaining referential integrity in our Realm. Really, this seems like such a basic function to ask of a database that we were shocked to discover it wasn’t supported automatically.

Third party

As of writing, Realm sits at v.0.95x or thereabouts. Meanwhile, CoreData was introduced with iOS3, and before that had been a Mac technology since Mac OS 10.4. It has a dedicated team at Apple who work on it full time.

No, I’m not claiming that CoreData is the be-all for your persistence framework choices. It certainly has it’s detractors. But it’s a mature and stable technology that the industry understands well. I would certainly expect an iOS developer to have working knowledge of CoreData. It’s actively developed, and recent iOS releases have seen big improvements to the way you work with CoreData (specifically parent contexts).

NSCoding is a foundational technology in Cocoa, on both the Mac and on iOS. Yes, it requires writing a bit of boilerplate to get your objects to archive and unarchive themselves, and it doesn’t offer faulting or any ability to run queries. But for a small object graph, I think it should still be your first point of call for your persistence technology.

Realm is another matter. It’s not even hit v1 yet; how can you be certain that you’ll be able to find developers who’ve worked with it next time you need to recruit someone ? Who do you go to when you’ve got an intractable problem ?

Yes, it’s Open Source, but really, who has the time to start forking a project the size of Realm and debugging it when you’re trying to debug and ship your own code ? Not I. And I certainly don’t get paid to debug third party software, when there’s a perfectly serviceable technology that ships with the OS.

If you integrate Realm - or any other third party technology (Parse, anyone ?), make no mistake - you have introduced a huge dependency and liability on something that is mostly, if not entirely, outside of your control. Is that something you want weighing on your mind as you try to hit that ship date and are neck deep in debugging some strange crash. Was it me or was it Realm ?”.

And if you do find a problem in that 3rd party code, are you really going to have to time to understand and fix it when your boss or client is jumping up and down wondering where his app is ?

My advice to you is to stick with the 1st party frameworks unless you have a very solid reason not to.

CoreData is solid and reliable, and although it requires careful setup and a good understanding of it’s peculiarities and quirks, that knowledge is widespread and mainstream. It takes care to set up your CoreData stack, but once done you won’t get much trouble out of it. And for less demanding needs, you’ve always got NSKeyedArchiver. Thats two ways to easily persist your data that ship with the OS.

cocoa objective-c swift
February 1, 2016

iPad Air 3 rumors: Everything we know so far about Apple’s next tablet

Apple shook up its tablet lineup last fall with the 12.9-inch iPad Pro, a laptop-sized device that supports stylus input from the Apple Pencil and snaps to a Bluetooth keyboard. Even the iPad mini got a major overhaul last year.

Surely the iPad will have to support the Pencil too. It seems like a no-brainer to me. Apple want, and need, to improve iPad sales - saving the headline feature of 2015/16 for just the Pro seems unlikely to go down well

January 31, 2016

Why iOS is Compelling

Just give into the seduction of iOS. Much like with 2Do, an astonishing amount of people right now are moving — in one way or another — to iOS as a full time computing platform. Perhaps not ditching the Mac completely, but at the very least declaring iOS ready for most of their work.

If I’m doing anything other than coding, I reach for my iPad rather than my MacBook. I have a sneaky feeling we’ll see some iPad Xcode goodness this summer too (maybe Swift Playgrounds) - which will give me one less reason to use the Mac.

January 30, 2016

It’s Coming: the Great Swift API Transformation

Cocoa, the Swift standard library, maybe even your own types and methods—it’s all about to change, and you can help determine how.

This is good news. Sometimes, calling back to the Cocoa APIs from Swift can break your mental flow as you re-adapt to the legacy naming conventions. Hopefully this review will also cover CoreFoundation too, which is particularly arcane.

link swift cocoa Apple
January 28, 2016

Xcode - the developer’s worst best friend ?

David Barnard posts a thoughtful piece about how Apple shapes the The App Store as an Economy.

It’s mostly spot on, but this off the cuff comment was a little harsh:

Tooling - It may seem far fetched, but the capabilities of Xcode shape the App Store economy. By pushing interface builder and auto layout, Apple has encouraged developers to build universal apps and made it more cumbersome to build separate iPad/iPhone apps. Bugs, crashes, and other deficiences of Xcode likely cost developers millions of hours of productivity each year, which has obvious implications for the App Store economy.

I think it’s a little egregious to claim that millions’ of hours of developer time is wasted due Xcode bugs, crashing and other failings. I use Xcode for a minimum of 8 hours a day as part of my job and I don’t recall the last time it crashed on me other than maybe when switching git branches that altered the project file in a major way.

It Xcode perfect ? No, of course not. I can list a number of things I’d like to see urgently - not least real refactoring tools and a better debugger (and the list goes on…)

But I think we have to also acknowledge the huge amount of time and effort that Xcode saves developers. Apple’s big push to use Autolayout has undoubtably saved me tens, even hundreds of hours personally, and new features like UIStackView will continue that trend.

Xcode’s recent improvements to units test support has also been a big benefit, encouraging developers to write tests and keeping them informed about their testing history. UI test also got a huge shot in the arm with Xcode 7.

I know that Apple know that developers have a love/hate relationship with Xcode. But they are obviously working hard on improving the tooling and the results are bearing fruit. I think the perception that Xcode is a buggy, crashy nightmare is at least a couple of years out of date.

What do we want ? Better tooling”. When do we want it? Yesterday” ! But in the meantime, Xcode actually does a pretty decent job.

development apple ios tools