Developing for iCloud sucks

iCloud is the thorn in Apple’s side.  They have been trying to get this right forever.  Maybe it works now from an end-user perspective, but as a developer, what a rough, confusing implementation.

I have to say, when you work with the Dropbox API, it is intuitive, it is easy, it is straightforward. Perhaps you have to write a lot of boilerplate code, but then again, do you?  It manages files.  This name, that path, that revision number, that modifiedDate.  You sort out the rest.  How hard can that be?

I’m currently writing a sync engine that allows users to decide which cloud service they want to use to backup their data.  So of course it would make sense to have one common API that wraps the various services.

It went so smoothly with Dropbox.  The only difficulty I had was realizing that the serialization of date strings sometimes results in small differences in the Date that emerges, meaning I had to write a .isTheSameAs(other: Date) method, which checks to see if they are within X seconds of each other, then call those ‘the same’.

Then I moved on to iCloud.  What a clusterf•ck.  Talk about over-engineering and complete inflexibility.  I just want a list of files that are in the cloud.  No, Apple has to distinguish whether you have them locally or not, and gives them a different URL.  And all sorts of other weird stuff.

So I tried to find a framework that makes iCloud a little more user-friendly, called iCloudDocumentSync which I found to be pretty straightforward, all things considered.  And yet, it’s still a pain.  Because iCloud uses multiple URLs to represent the same document.  In the end, I have to sync the entire iCloud folder’s contents before I can start working with these with a common URL.  (Sure I could extract the file name I need).  Moreover, iCloud uses a thread to open each document, so if I want to batch download a lot of data, suddenly I have a thread explosion.  Now I have to deal with managing that.

All in all it’s just been a pain to work with it.  It seems opaque in its verbosity.  Meaning, the person who talks a lot doesn’t get listened to and understood.  There are so many callbacks and all sorts of weird things going on, it’s very annoying.  Just because they’re trying to save the developer time, they’ve implemented something weird and unwieldy if you don’t use it according to their use case.  I personally just use a UIDocument as a means to save data.  I don’t work with UIDocuments because my app’s data model uses the data, but not the file.  This just seems silly with iCloud.

Alamofire and nostalgic feelings for AFNetworking

So, in the Swift world, I presume a lot of people prefer to remain “Swifty”.  That is, why would you opt for old Objective-C libraries?  Out with the old, in with the new!

So, we adopt Alamofire.  Is it just me, or is this library a bit unwieldy?   I think it has a lot to do with Swift shorthand and often not knowing just what types are actually being passed around, especially given autocomplete.

On top of that, just when you get your head around a specific release, they make a new major release, breaking old APIs.  And if I’m going to have to keep updating my code to stay current because “out with the old, in with the new”, why don’t I just stay with AFNetworking?  I mean come on.  It’s networking.  For the mostpart it’s just “give me that data at that URL.  Here’s my auth info.”  Done.  Or “here’s some data for you.  Here’s my auth info.”  Done.

Anyway, it’s a rant.  I just don’t find Alamofire all that sexy.  It reminds me of dealing with civil servants.  The creators imagined this bureaucratic utopia that functions perfectly as long as everyone understands it.  Furthermore, we must not only understand it, but are fully on board with its vision.  Meanwhile, we the people are busy trying to write our own apps, and couldn’t really care less.  We just want to get data and post data and not have to deal with too much crap in the middle.

(Go ahead, snarky programmer.  Now tell me off, tell me to just use this, that, or the other.  Reject my feedback.  It’s fine.  All I’m saying is that AFNetworking seemed a lot easier to use.)

Why I Still Don’t Use Swift in Real Projects

(UPDATE:   My opinion has changed)

So, every so often, when I’m not busy making production apps for clients that have to work, be reliable, be easy to read, be easy to extend, be easy to debug, and so on, I have a look at Swift.  I know I’m admitting something that perhaps one best not admit; I don’t use Swift yet, really.  I haven’t fully embraced it.  And I’ll tell you why.

I’m a creative developer.  Also, I live in Germany.  I therefore hate bureaucracy.  There’s a connection.  Germany for me has at times been a near death experience…. death by 1000 paper cuts.    With Objective-C, and all those Cocoa Frameworks, I know these tools very well.  As a creative developer, I am as interested in the beauty of the project on the outside as I am with the beauty of it on the inside.  I would reckon I’m pretty good at writing Objective-C code.  Obviously because of experience and a commitment to quality.

I understand there’s a learning curve with anything new.  I get that.  I clash with Swift when I have a creative idea and I just want to build the thing I want to try out.  App development is a strange voodoo; you can have a good idea on paper, then once it’s in your hand and you interact with it, it makes that idea perhaps less awesome or less useful than you thought.  So, the ability to do rapid prototyping is of great interest to me.

Enter the strictness of Swift and its compiler.  For me it’s like going to any German ministry to get something done.    You turn up with your form (well, forms) with the hope of getting it stamped and approved today.  They turn you away for some reason.  It’s always some reason.  Sometimes they invent reasons because they don’t like the look of you. The civil servants don’t think creatively nor solution-oriented.   You can’t ask for help.  You only have to state what function you would like them to carry out today.  The number of times they give you that stare as if to say “Invalid input.  Invalid input. Invalid input.” and you expect smoke to start billowing out their ears at any second.  Similarly, the Swift compiler annoys the hell out of me because the error messages are still kind of cryptic, not always referring to the actual error and potential solution to the problem (comparing to Objective-C here… which also loses its way from time to time). Basically “sorry, can’t do it.  Go bother someone else.”

No, I’m a free spirit.  I like the dynamic nature of Objective-C.  I like being able to say “I know this is bending the rules a bit, but please just do it, because I know what I’m doing here.”  and the compiler will do it.  Maybe your code crashes at runtime, but maybe not.  In the end, experience will often have a strong say here.

Say I actually did get my Swift code running.   I’m not an early adopter.  I’m just not.  With any software product, I prefer to sit back and wait, let them iron all the kinks out, then I’ll be interested.  I have too many other hobbies and interests that also take my time, so to want to update my old, running code, because now the language itself has changed and is no longer compatible and I am forced to update it, just so it will run, does not sound like a desirable use of my time.

Then I hear just around 10% of apps in the app store actually have Swift code in them.   People make it seem like if you can’t code in Swift you are massively behind the times and are unemployable because it’s *all Swift* now….

I don’t know, for all these reasons, I still sit back and wait.  I try to keep up on the language in general, but for me I’d just like to say “sort yourselves out, and let us know when it’s ready for general consumption, because right now I don’t like make-work projects.  I just want to build great things, quickly.”  Sitting in front of a cryptic compiler error message because of typing or unwind errors is not my idea of swiftly creating anything at all.

An Open Letter to (mobile) Server Devs

On basically every project I’ve ever worked on that involves a server, I seem to notice the same things that happen over and over and could be preventable with proper planning.  When mobile devs discover server bugs, it often blocks our work and halts development (not to mention the costs associated with that, which are NOT trivial).

So I thought I’d just list the things that I wish server developers would think about when they start building a system, and rant a bit about the mentality we’d hope for in any server dev.

 

Design for the failure case, not the ideal case.

Servers fail all the time.  You should consider what will first go wrong before you focus on what will go right.  If you set up your architecture correctly at the beginning, this becomes easier.  Yes, your project has more boilerplate at the beginning, and you can’t just dive into the things that make programming fun, but remember you are a server; you serve others.  The quality of your work is measured by how close to perfect your work is.  Nobody knows when things are working correctly, but they DO know when they’re not.  It’s a tough life as a server dev because you get very little love.  But you chose that, so what should I say?

Consider at the very start how you’re going to deliver errors to the clients.

 

Think of responses like a textual representation of an object.

I come from Object-Oriented Programming.  Think of responses as objects, and you need an application-wide “baseclass”.

{
    "data" : {
        /* YOUR ACTUAL RESPONSE PAYLOAD HERE */
    },
    "errors" : [
        {
            "code" : 401,
            "domain" : "HTTP",
            "description" : "Unauthorized",
            "recovery_suggestion" : "Your access token may have expired.  Try logging in again."
        },
        {
            "code" : 1001,
            "domain" : "Our Server Form Validation",
            "description" : "Email address invalid",
            "recovery_suggestion" : "Make sure your email is formatted correctly."
        }
    ],
    "message" : "Any arbitary message that is relevant to the response itself.  This response isn't supposed to make sense for any specific context.  They're example fields.",
    "response_time_in_ms" : 1234,
    "status_code" : 200
}

 

It’s not 1982

Mobile Clients prefer textual representations in the response.  Your responses can be verbose and at times redundant.  If you have to echo the http response status code in the payload, why not?  All the pertinent information is in the same place.  To an extent, of course.  It just makes your API that much more easy to work with.

 

The Importance of a Documented API

Your server may be down.  When your server is down, your mobile developer is often stuck when he doesn’t need to be.  Most of the time, mobile devs need any data, so long as it can be used to populate the contents of the UI.  The Server API is a contract.  It specifies what the server team will deliver, and what the mobile developer can expect.  It ensures that two mostly separate teams can work happily in parallel.

If you provide a documented API before it’s even implemented, the mobile dev can get his job done.

It just needs to be simple.  Send these parameters with this method to this endpoint, and you can expect a response of:  (most verbose response here that shows all possible fields that might be defined.  Mark in comments beside that value if NULL can be expected.)

Then you highlight the error scenarios.  Possible error codes and why.

 

Interactive API via Postman

Postman is a very valuable tool.  It’s generally how you resolve disputes with the server devs to the effect of “Server’s broken!  No it’s not!”  You can make your requests outside of the app and inspect how the server is working.  It also makes your bug reports more believable to a server dev, where he can’t really say “stupid user error”.  It’s of course up to the server dev to keep environment variables up-to-date and provide some documentation on how to use Postman in the way the server dev expects you to.

 

This is sort of a working draft, but on almost every project, I wish there would be devs that understand how their work makes its way into the end product.  And if you ensure that your role is one of service, and your customers are mobile developers, keeping a service-oriented mentality, like the Maître d’Hotel, where you derive your happiness when your customers are happy, this surely is the way for you to become a rockstar.

Excellent Definition of a Senior Software Engineer

Found this on Quora and it certainly justified my job title! 🙂

What does this mean for a software engineer: “You are not at a senior level”?

QUOTE:

The Perils of Hackers in your Team

I’ve currently joined a project as the only iOS Developer.  I’ve inherited a codebase that’s passed through the hands of 4-5 guys over the course of 3 years.  3 years is already at least a yellow flag in terms of iOS Development.  In my view, the only reason the same project should be allowed to live for 3 years is if you have older devices to support, or a massive userbase and a fat client architecture (making loss of data an issue).  For startups, you should always consider re-writing your Minimum Viable Product, as so many lessons are learned, so many pivots are made, so many corners are cut, to get you to where your codebase is today.  Cruft (look it up) is your biggest problem.

Poorly structured code will hurt your bottom line.  It becomes increasingly expensive to work with, and adding new features will not be easy, and the chances of introducing bugs will be high.  As much as one can talk about Test Driven Development (TDD), I’ve rarely heard of teams (in the startup world at least) that write tests, and if they do, they write them *after* the code has been written.  (This has proven to be the most expensive way to implement tests).  So, fine, the world is not perfect.  In these cases I would hope that if you are a developer reading this, you will at least put comments in your code and also NSAssert statements (the poor man’s sanity check / testing shortcut).

Let me now define what I mean by Hacker in the context of this post.  A Hacker is someone who may look good to any non-developer.  He gets the job done.  The code “works”.  He appears passionate as he types away in a frenzy, trying to make things ‘just right’.   The thing about a Hacker is that he may be self-taught and completely lack the principles of good software design.  He writes spaghetti code (that works).  He may say things like “I don’t need to put comments, the code should speak for itself.”  (If that’s true it is saying “Help me!” or “I’m taking hostages!” or “Your time now belongs to me!”).  But the worst thing about a Hacker on your team is that he will write code that is often a testament to every anti-pattern you have ever known, and to have to work with that person’s code is like being sabotaged before you can even begin.  Because to work with that code, you essentially have to rip out everything he’s done to make the codebase useable again.  So before you can begin to be awesome,  you have to weather the storm of management (who can’t possibly know your struggles) saying “I’m noticing progress is slow”, or “but it’s working now, what do you mean you need to rewrite it…?”

In short, a Hacker in charge of your codebase is basically signing a death warrant for your current codebase, or paying for a huge financial hangover after he’s gone.  A Hacker on your team can have some benefit (thinking outside the box, enthusiasm), but be wise and make sure he’s not in charge of architecture, and make sure you do code reviews.

I’m slowly beginning to like Core Data

Core Data is by far the worst framework I have ever had to work with. Or is it?

It has a steep learning curve. Though once you’ve got your head around it, it doesn’t seem so bad after all.

I’m really starting to get accustomed to it. There are just some principles one needs to know in order to really not hate it.

I use the MagicalRecord library on top of it, and the mogenerator tool to make everything manageable.

I’ve got multi-threaded code and it cooperates (so far).

My approach is to keep most update operations off of the main thread, and saving that background context will update the main thread context, which in turn updates all the NSFetchedResultsControllers, and now my table views just animate those changes nicely!

I think, after numerous attempts, I am finally getting to be fit with CoreData and now can use it as my main persistence framework from now on. (Until they scrap it and move for something more Swift-style…)