Why I Still Don’t Use Swift in Real Projects

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.

iCloud Drive – What a disaster!

So, I’ve been working on a new version of my app Songbook Simple and I want to improve some of the file sync code.  Up until now I’ve been supporting Dropbox, with the original idea that a user can edit and modify all his/her songs from the convenience of their desktop, and it would just sync on the device.  This *has* worked, and *still* works, though it always seemed like a quick and dirty solution to me.

Enter Apple TV.  I thought it would be fun to make Songbook Simple Apple Tv compatible, but in order to do that, one basically has to support iCloud for syncing data.  As the Apple TV won’t be an editor, but just a viewer, we need to get data from somewhere, and I’m not so sure Apple TV is entirely Dropbox friendly yet.

So, I’m trying to implement iCloud support in Songbook.  I followed the excellent 4 part tutorial series written by Ray Wenderlich himself.   It all seemed to work brilliantly.  Files were syncing across iOS devices.

But wait.  Now what about using my Mac to edit files?  Well, turns out this is where iCloud Drive is a complete and utter disaster.  On icloud.com, there is no folder associated with Songbook.  On iOS, the iCloud Drive app DOES show my app folder and its contents.  On OSX, in the iCloud Drive folder, you don’t see anything associated with Songbook.  So my user workflow, namely, editing songs on your Desktop, is broken.

I’m all for “Automagic” for the sake of better User Experience, but if it’s “Autobroken”, then get rid of your magic because you’re killing us.

In order to restore the ability to edit the contents of my SongbookSimple folder, I had to open a terminal window, and do the following:

cd ~/Desktop
ln -s ~/Library/Mobile\ Documents/iCloud~com~softwarebarn~SongbookSimple/Documents/

Then, from Finder, navigate to the Desktop, then either move that Alias that just got made (called Documents) to somewhere better, or simply drag it into my Finder’s sidebar.

Great feature, Apple!  All these years to mimic Dropbox and it’s still a failure.  Yes, I followed ALL the instructions, and spent 3 hours this morning making sure I didn’t miss any.

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.

HSHTMLImageRenderer !

So with permission of my current client (for whom I wrote the original code), I’m able to open source this component for all to use. I’m delighted I can do that because I think this component can be of good use to people.

HSHTMLImageRenderer is a way to be able to render HTML offscreen to images that can be stored in a cache.  It’s useful when you have many layout elements whose content is a small bit HTML that could be complicated and unsuitable for a UILabel, and it’s not feasible to have numerous instances of UIWebView everywhere.

Have a look. It’s over on my github page.

Multi-Threaded Core Data Solution

I’ve been wanting to revamp some old code that wasn’t performing as I like.  I had come up with something a bit too complicated involving NSOperationQueue, fetching remote data, parsing it all in the background, then saving that to my Core Data’s persistent store.

I always thought my solution a bit too complicated, and not sure it was entirely correct / robust.

I don’t know about you, but I regularly have 6-7 Google Chrome windows open with tons of tabs.  I have some articles that sit there for months that I don’t want to forget about.  One of which was written by Marcus Zarra, a prominent source of Core Data info.  He made it look so easy.

I’ve come to enjoy Core Data as a framework.  I think there is no other way at this point.  And I’m sure I’ve only scratched the surface of what it can do.  Along with mogenerator in your build pipeline, and especially the associated controller (NSFetchedResultsController) this framework is indispensable.

I basically took Marcus Zarra’s post and extended it to allow for doing data model work in the background, and also for making “scratch pad” contexts.  That is, consider editing forms but then the user hits “cancel”.  No rollbacks needed.  Just discard the “editor” context.  Or, consider data imports that run in the background, and you are on a view controller using an editor context.  You can even tell that editor context to update itself with those changes that occurred in the meantime.

Anyway, all a bit vague, so I’d like to just refer you to my repository that demonstrates what I’m talking about at http://github.com/horseshoe7

Please clone it and run it.  So a search for scenarioToExamine and change that value.

UPDATE:  I just found and read this article by Florian Kugler.  This solution above is an implementation of his so called “Stack #2”.  I really want to have a solution that’s going to be versatile and fast, so expect my repository’s implementation to change to be “Stack #3”.  Will update again after this happens.

UPDATE 2:  So I found my solution.  It’s in the Repo.  It’s called HSHybridThreeStack.  It has Marcus Zarra’s asynchronous background saving context, it has Florian Kugler’s separate context for speedy importing, it has main thread editing contexts that can optionally keep themselves updated to changes resulting from these import contexts, and an API that should be pretty straightforward.  You could refactor the HSCoreDataStack protocol and just incorporate it into one baseclass, but I kept it as such so that my various implementations were completely separate from one another.  So there is a lot of code repeated across implementations.  It is a Sandbox project after all and doesn’t represent an incredible approach to architecture.