Category Archives: software dev

Launching Codeless

So, it finally happened.  My team and I got Codeless into the App Store.

I started writing Codeless off the side of my desk in 2015.  I had a couple weeks between projects, and I thought there was no way this could take more than a couple of weeks to prove the concept.  Here’s the oldest screenshot I could track down from July 30, 2015.

C74A0255 9196 4713 8DCB 3D0EE6D559BE 1 105 c

These days, it looks more like this:

Simulator Screen Shot 2nd gen iPad Pro 2020 05 12 at 01 21 26

It’s just beginning, but I think it’s gotten pretty good.  If you’re into app design and you’ve got an iPad, give it a download and tell me what you think!

P.S.: Thanks to Adam, Brendan, Jen and Owen.  This thing wouldn’t exist without you all.

Prelude to codeless

I love working on side projects, but I don’t usually talk about them until they’re ready to demo.  

What if I decide this isn’t worth pursuing in six months?  What if this turns out to be vapourware – will that hurt my reputation?  When I go down a blind alley and have to turn around, will I look stupid in front of my peers?  What happens if we get really busy at work and I can’t make any progress for a month?

On the other hand, I have a burning desire to try and build a side project ‘in public’.  I want to get people excited about this project, and I want to see if people are interested in it before I get too far down the path of building it.  I want to build the projects reputation, so that on launch day we’re ready to talk about it confidently.  And I want to tap into the hive mind that is the internet and see if anyone suggests something I never considered.

With that in mind, I’ve decided on a couple things.  I’m going to tell you about a side project I’ve been working on, only a few weeks into it’s life.  I’m going to try to stay open about it, and to tell you about where it’s gone and where it’s heading.  And I’m going to commit to releasing it as open source if I ever decide to put it on the shelf for good.

The problem we’re solving

I find it pretty frustrating how apps are designed right now.  Static mockups are made 

I get really frustrated with apps designed in photoshop…

…because it feels like someone handed me storyboard mockups and claimed they were a completed film.  I’ve been running an consulting company that specializes in mobile development for the last three years, and I’m always annoyed when a designer hands me a photoshop mockup for the app.  Because I know they’re going to want it translated to the screen in a pixel-perfect fashion, despite the fact that they built it in an image editor, and not on the platform.

Here are a few things that commonly fail in translation:

– Font rendering is different across platforms.

– Sometimes things look better on a 30” monitor than a 3.5” device.  Button sizes that look perfectly reasonable in photoshop are usually impossible to hit.

– For that matter, we usually only get photoshop documents for a single size of screen, and it’s usually not the largest or the smallest.  Apps designed this way are usually too tight on small screens and too spread out on large ones.

– Often there’s a graphic effect they’ve carefully tweaked, but want rendered live.  A blur over content is a common example.

These are all things that get screwed up in translation.  I’d like to be able to design apps on the actual device, with the native elements, so that I know things will render the same way in the final product.

We’re also wasting a lot of time and money

In the current model of handing off mockups, two expensive people doing the same work over.  The designer does a great job in photoshop, then the developer has to do the *same great job* in code.  And the developer is probably going to miss some subtleties.  Just look at how hard it is to do those ‘find ten differences’ puzzles you see in newspapers. Right now, every screen of the app is one of those.

No, I’m not saying the entire job of a designer is positioning elements, but the final output is a graphic file.

The ultimate aim for a mobile design app would be to output actual compilable code at the end.  Let the designer do their job in the *actual medium*, and let the developer take that work and build on it, not redo it.

So…codeless?

codeless is an iPad app I’ve been working on.  It’s in the early days right now, only supporting a few things like view positioning and some basic property editing.  But it’s going to be great.

Think of it as a cross between Photoshop and Interface Builder, with a little bit of Invision App thrown in for good measure.

It’s ugly as sin right now.  Here’s the first screenshot.

codeless screenshot

You can probably tell, there’s quite a ways to go.  Come with me.

Concept and Execution

Matt Gemmell tweeted this lovely concept of the Macintosh Nueu from Curved Labs.  It’s a stunning piece of design work that immediately sets off a twinge of nostalgia.  Familiar in both 1984 and 2015, the design resonates.

I loved the design of the original all-in-one Macs.  I keep a Mac Plus and a Classic II on the bookshelf in my office.  Maybe it’s just because I used them in my childhood, but they evoke a sense of wonder that more modern technology struggles to match.

With few exceptions though, I dislike concepts.  They give me a sour feeling in my gut.  As someone who’s often tasked with turning bright ideas into reality, I’m deeply uncomfortable with presenting a cool idea in such a factual way.  Concepts make for great art, but they’re terribly misleading when it comes to portraying what we should actually do.

Executing on an idea brings forward all the sharp corners and rough edges.  We almost never know what the actual problems in a development cycle are going to be until we’ve finished the first pass at implementation.  Oh sure, you can spot some of the dangers from afar, but that doesn’t mean there aren’t more lurking horrors that will require a course correction midstream.

If you can execute on the idea and it’s still a good idea, you’ve got a winner.

What Do You Call Complete?

Sometimes I worry about the level of completion that I’m willing to take before shipping.

On one hand, clients tell me that they love the sense of taste and little details that I bring to a project, but on the other hand I’m always convinced that I’m shipping too early.  That’s not just programmer paranoia either.  We’ve lost clients before by sending a beta that didn’t measure up.  I’m not proud of that, but it’s led us to better ways of testing and of communicating, so I’m not torn up about it either.

Once, six or seven years ago, I had a customer berate me for shipping beta quality software.  It was on the release of a 2.0, and I had a 2.0.1 out the next day for him, but I still feel disappointed in myself for letting that get by me.  Every other email I got on that release raved about the new features, but the one I really remember was the humiliating one.

Developers are great at ensuring code quality, but often we fall down on product quality.  Beta groups, integration testing, PM feedback, all that can only get you so far.  Eventually someone tries something you didn’t see, and now you’ve lost a customer.

I’m sure if I got a better business person in here, we’d talk about the cost tradeoff of quality control vs. keeping a customer.  But that doesn’t sit well with me.  I want to make amazing software, and too often I have to settle on good enough.

How do you measure that software is complete?  I feel like we need a role in the organization that’s just ‘software critic’.  Someone who doesn’t give a damn about what tradeoffs had to be made and where the budget was set.  If we can frustrate that person, then maybe it’s ready to ship.

How do you measure that software is complete?

UIWebView in XCTest Cases

I ran into an interesting problem today while trying to write some unit tests for an SDK we’re helping to build at work.  It involved instantiating a third-party library, then running a few tests to be sure that our delegate code was being called as expected.

The problem is that the third party library contained code to instantiate a UIWebView.  At first I was puzzled.  That couldn’t be causing a crash.  I ended up stripping out the actual test and just putting in a line like this:

UIWebView *wv = [[UIWebView alloc] init];

And an exception was thrown.

After Googling around for a while, I came across a Stack Overflow post discussing the behaviour.  It looks like when you’re trying to test UIWebView in a static library, it needs an app target set to run.  I created an empty app, set it as the target, and boom, we had a working unit test.

It’s the things like this that make me realize that I’ll never be done learning.

Intents in Android

If you’re an iOS developer who’s never had a chance to work with Android, there are a few things that you should have a look at.  My favourite part of Android is the Intent system.  It’s an easy and flexible way for apps to add features.

In iOS, when you want to allow the user to send an email from within your application, you instantiate an MFMailComposeViewController and present it.  But what if you’re a Gmail user?  We’re stuck sending you through the default mail sheet.

On Android you instead send an mail intent.  This is a way to say to the system “I want to send an email”.  The system picks your default mail app and presents a send screen.  It’s far more flexible and respectful of user choice.

Mail is just an example.  You can send an intent to do just about anything, and define custom intents of your own.

Extensions in iOS 8 look like they’re bringing a level of this flexibility to iOS.  I’m eager to see if the implementation results in the same explosion of choices available on Android.

Re-signing Apps

At Whole Punk, we’re working on a new product that removes an awful lot of the grunt work from UI testing.  We’re using UIAutomation to build full state graphs of the UI, and then generating a pretty doc of all the screenshots and crashes we detect.

It’s a brute force approach – it takes hours for a mid sized app or days for a large one.  But who cares?  I’m happy to have a computer do a days worth of work so I can spend ten minutes reviewing the UI for unexpected display bugs.

The alternative is that I’d do the work myself.  I’m also thrilled to have a computer in charge of finding the low-hanging crashes and handing me reproduction scripts.  Most companies we deal with hand this sort of testing off to an intern.  We think a computer is faster, more comprehensive, and ends up giving better data.

Enough with the sales pitch.

In order to do this testing, we need to be able to run UIAutomation scripts via instruments.  One of the restrictions we ran into is that we can only run UIAutomation scripts on apps that are signed with our development profile.

Since our ambition is to run this as a service, we needed a way to resign apps with our development profile.  The answer turns out to be pretty simple:

/usr/bin/codesign -f -s “YOUR_DEVELOPMENT_CERT_NAME” —resource-rules APP_PATH/ResourceRules.plist —entitlements ENTITLEMENTS_PATH APP PATH

The entitlements file should contain the following:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>get-task-allow</key>
<true/>
</dict>
</plist>

 

And voila, we can run UIAutomation against apps we didn’t build.


Technologically Conservative

Within two weeks of the Swift announcement, clients were asking me if I thought we should be writing new apps in Swift.  The answer, and I hope this doesn’t surprise you, is a resounding NO!

Swift needs time to stabilize.  We need to write plenty of bug reports and feedback on it.  As a community, we need to learn where it’s limits are and establish a new set of best practices for it.  I’m not shipping code on a platform that’s still defining it’s syntax.

As soon as I make those points, everyone nods and agrees.  “Hm,” they say, “we hadn’t realized that it’s still in flux.”

It’s not just languages that have this issue.  A version one of any API as almost moving a little bit.  Sure, the method calls might stay the same, but the behaviour can change subtly underneath you as bugs are fixed and edge cases are recognized. [1]

I do my damnedest to avoid shipping code that relies on new APIs [2]. I don’t like shipping code when I don’t fully trust the libraries beneath it yet.

That said, of course I’m working on side projects with Swift and all the new APIs that catch my attention.  Though I’m conservative in what I ship, I’m far more liberal in what I code.

I like my side projects to push into the new and shiny.  In the words of The Friz: “Take chances, make mistakes, and get messy!”

There can be a fine line between being conservative in your views and being regressive.  Make sure you’re pushing back for the right reasons.  Colour outside the lines when you can.

Footnotes

[1] It’s easier to recognize when your compile breaks as the language updates, but shifting APIs can break your app too.

[2] Unless the goal is to get featured in the App Store by using the newest APIs.  That’s certainly not a bad goal.