WWDC 2016, or close to that

My first WWDC was 15 years ago. I was part of a few youngsters who were selected for the student scholarship, and back in the day, there were a lot of empty seats during the sessions. It was in San Jose, and my friend Alex was kind enough to let me crash on his couch for my very first overseas “professional” business trip. Not that I made any money on that trip, but it was beginning to be my career and I was there in that capacity. A month later, I would be hired at Apple in Europe, and Alex would be hired by the Californian HQ a few years later, but back then, what mattered was to be a nerd in a nerd place, not only allowed to nerd out, but actively encouraged to do so.

I was 20, give or take, and every day, I would have lunch with incredible people who not only shared my love of the platform, and the excitement at what would become so huge – Mac OS X, Cocoa, and Objective-C-, but would also share their experiences (and bits and pieces of their code) freely, and for the first time in my short professional life, I was treated as a peer. I met the people who came out with the SETI@Home client, and were looking for a way to port it from Linux to 10.0 (if you’ve never seen 10.0 running, well… lucky you), I exchanged tricks with the guy who did the QT4Java integration, and met my heroes from Barebones, to name a few.

Of course, the fact that I was totally skipping university didn’t make me forget that, like every science, programming flourishes best when ideas flow easily. No one thought twice about opening a laptop and delving in code to geek out about a specific bug or cool trick. I even saw and maybe had a few lines of code in a Lockheed Martin hush hush project… Just imagine that!

Over the years I went regularly, then less so, and in recent years not at all. It’s not a “it was so much better before” thing as much as a slow misalignment of what I wanted to get out of it. Let’s get this particular thing out of the way, so that I can move on to more nerding out.

Randomness played a big part for me. I met people who were into the platform, but necessarily living off of it. Academics, server people, befuddled people sent there by their company to see if it was worth the effort porting their software onto the Mac, it was that easy to get in the conference. These days I dare you to find an attendee who has a paid ticket and isn’t making a living from developing iOS apps (either indie or contractor, or in-house). The variety in personnalities and histories, and uses of the platform is still there, but there’s zero chance I’ll see an astronomer who happens to develop as a hobby… As a side note, the chance that a presenter (or Phil Schiller, who totally did) will give me his card and have a free conversation about a nerdy thing, certain in the fact that we were part of a small community and therefore not abuse each other’s time is very close to zero as well. Then again, who else was interested in using the IRdA port of the titanium to discuss with obscure gadgets?

So, it felt a little bit like a rant, but it’s not. I recognize the world has moved, and Apple went from “that niche platform a handful of enthusiasts keep alive” to the biggest company on Earth, and there is absolutely no reason why they should treat me differently for that past role, when there are so many talented people out there who would probably both benefit more from extra attention, and prove a more valuable investment. Reminiscing brings nostalgia, but it doesn’t mean today is any worse from an imagined golden age, when the future of the platform was uncertain, and we were reminded every day that we were making a mistake by the rest of the profession. Today is definitely better, even if that means I don’t feel the need to go to the WWDC anymore.

So, back to this year, the almost live nature of the video posting meant that I coded by day and watched sessions by night, making it almost like those days when sleep was few and far between, on the other side of the world. I just wasn’t physically in San Francisco, enjoying the comfort of my couch and the possibility to pause the video to try out a few things the presenter was talking about, or the so very important bathroom break.

All in all, while iOS isn’t anything new anymore, this year in particular, I was kind of reminded of the old days. It feels like we’re on a somewhat mature platform that doesn’t revolutionize itself every year anymore (sorry users, but it’s actually better this way), the bozos doing fart apps are not that preeminent anymore, and we can get to some seriously cool code.

2016 is all about openness. Gone are the weird restrictions of tvOS (most of the frameworks are now on par with other platforms, and Multipeer Connectivity has finally landed). WatchOS is out of beta. We can plug stuff in first party apps that have been walled off for 8 years. Even the Mac is getting some love, despite the fact it lost a capital M. And for the first time in forever, we have a server session! OK it is a Big Blue Man on stage but we may have a successor to WebObjects, folks! What a day to be both a dinosaur and alive.

Not strictly part of the WWDC announcements, the proposed changes to the App Stores prefigure some interesting possibilities for people like me, without an existing following or capital that can pay for a 6 months indie project. Yes, yes I know. There are people who launch new apps every day. I’m just not one of these people. I enjoy the variety of topics my customers make me confront to, and I have very little confidence in my abilities to manage a “community” of paying customers. Experience, again, and maybe I’ll share those someday.

Anyways, Swift on Linux, using frameworks like Kitura or Perfect right now, or the future WebObjects 6.0 might allow people like me, who have a deep background in languages with more than one type to be able to write fairly rapidly and consistently a decent backend, and who knows maybe even front end. Yes, I know Haskell has allowed you to do similar things for a bit, but for some reason, my customers are kind of daunted by the deployment procedures and I don’t do hosting.

The frills around iMessage stickers don’t do much for me, but being able to use iMessage to have a shared session in an app is just incredible. So. Many. Possibilities. Completely underrated in what I heard from the fallout of the conference doesn’t even begin to describe it. Every single turn based game out there, playable in an iMessage thread. I’ll leave that out here. See? I can be nice…

MacOS (yes I will keep using the capital M because it makes more sense to me) may not get a flurry of shinies, but benefits largely from everything done for iOS, and Xcode may finally make me stop pining after Codewarrior, or AppCode, or any other IDE that doesn’t (or didn’t) need to be prodded to do what I expect it to do. Every time I have to stop writing code or debugging code to fix something that was working fine yesterday, I take a deep breath. Maybe this year will grind those disruptions to a halt, or at least be limited to the critical phases of the project cycle.

I like my watch. I may like it without having to express an almost shame about it, come September. Actually, while I’m not tempted in the least to install iOS 10 on any of my devices just yet, I might have to do it just to have a beta of the non beta version of watchOS.

In short, for not quite defined reasons, I feel a bit like I did, 15 years ago during my first WWDC. It looks like Apple is shifting back to listening to us developers who aren’t hyper high profile, that the platform is transitioning to Swift at a good pace, but not just bulldozing it over our dead bodies, and that whatever idea anyone has, it’s finally possible to wrap your head around all the components, if not code them all by yourself using a coherent approach.

Hope feels good, confidence feels better.

Mood : contemplative
Music : Muse - Time is Running Out

UIkit and AppKit unification

The latest fad in tech punditry is to claim the barrier to have iOS apps on the Mac is the fact these two graphical frameworks are so different that it makes the work of developers too complex. This is false.

Let’s start with the elephant in the room: an app generally has to bring more to the table than its UI. But the underpinning coverage is total. There is less than 5% of classes and methods that are available on iOS and not on the Mac. On the other hand, there are more methods in the same frameworks on the mac side. So for everything but the UI, “porting” only means recompiling. If your MVC is well implemented, that part at least won’t cause any issue.

The UI part is a mixed bag, but the paradigms are the same nowadays. It wasn’t the case until fairly recently but table views are cell or view based, the delegates are as expected, etc, etc. As an experiment, on uncomplicated examples, I did search and replace only, no tweaking, and it worked.

Now, of course, the issue isn’t technical: the iOS mono-window and mono-view is wasted on the mac. A lot of applications take the “landscape ipad” paradigm to make it less obvious, including Apple : you have the sidebar and the main view, and it works just like the master/detail project template that comes with Xcode.

Porting a successful app from iOS to the Mac is indeed a bit of work. The Mac is window centric and iOS is view centric. Some things you cannot do on iOS are possible on the Mac, like covering parts of your UI, or dragging and dropping elements. It is definitely a very different way to think about the user experience, and the design choices are certainly less constrained and less obvious. But there is no real technical hurdle, unless the vast majority of your app logic lives in the view controllers rather than in a separate codebase. And then again, the Mac now has NSViewController that works exactly like, who would have guessed, UIViewController, and apps can run in full screen mode, so who knows?

The tools (Xcode, IB, etc) are the same. The non UI frameworks are the same. The UI frameworks are similar where it makes sense (putting stuff on screen) and dissimilar where you have to (input methods and window management). That’s it.

Now, you can definitely agree that the Mac app landscape is very different from the iOS one. People are used to having giant things that install other things everywhere, demos, sharewares, unrestricted access to the filesystem, the possibility to copy and paste anything from anywhere, or drag and drop anything from anywhere, and to put it somewhere else, where it will do something. They have multiple apps that come and go depending on modal dialog boxes that show up, and pieces of stuff like palettes that they can arrange any damn way they please, thank you very much. For all these reasons, designing a successful Mac app is challenging. Big screens, small screens, people who like lots of little windows, a few big windows, people who use spaces, people who use keyboard shortcuts more than the mouse, people who don’t know how menus work, people who have a gazillion of menu items, fonts that can be changed systemwide, colorschemes, those are all valid reasons to dread an attempt at making an app that will appeal to most people.

But you don’t get to play the technical hurdle card. All these interactions have been studied, refined, and solved over 30 years of graphical interfaces. You have to choose what will work best for your needs, and yes, this is hard. But it’s not about code.


Automagic Asset Generation For Apps

Between the iPhone (non retina, retina, 3x), iPad (non retina, retina, and pro), and Watch (2 sizes), generating an icon for all those things necessitates no less than 26 images. I have been using a custom Automator script to generate them all through a service that accepts any image as an input, which grew quite big.

As I was updating it, I thought it might be a nice thing to do to let my fellow sufferers have it. So, if that is something you think you might have a use for, feel free to grab it. As a matter of course, it works for me, but I make no promises for your workflow. Just drop me a line if you want to say thanks, make modifications you think might be useful for others, or throw curses at me for having released that just as you finished yours.

It uses no dependancies on libraries or custom applications, by the way.

Download XCAsset Automagic Generator right here!

Mood : working
Music : Griffin House

[Rant] Collaboration on Code

It so happens that we just found a bug that plagued us for 6 months, in the form of a commit that ignored completely the existing code in favor of a copy/paste from an internet source (I assume).

Now, let’s get one thing out first. I really really don’t mind having stack overflow code in my source. It has, over the years, established itself as a reliable way to fix thorny issues, or at least find pointers, and is probably todays numero uno origin of most code written by new programmers. That’s fine. Better than fine, it’s totally rad to have a community help students and people exploring new fields of our wonderful pitfall-laden world.

The second thing I want to point out is that I have worked freelance for 16 years. That should tell you my teamwork leaves a lot to be desired. I know that.

Now, every now and again, I still have to work with existing code, being updated while I work on the project. That’s fine too. However, successful collaboration, especially on code, relies heavily on communication, and prepwork.

So, without further ado, the Cardinal Rules of Team Code Editing (at least when I’m involved):

  • Thou shalt have a clearly defined “ownership” system. What parts of the code are you responsible for? What parts has someone else in charge?
  • Thou shalt have a clear way to communicate the changes thou art making. No, commit logs aren’t enough. At least not on their own.
  • Thou shalt always check thrice as much when changing code thou doth not have ownership thereof. If you “fix” something in someone else’s code, you’d better be pretty bloody sure you understood how the owner made that piece work.
  • Thou shalt notify the owner of the code of thy changes. Email, Slack, IM, Skype, I don’t care how.
  • Thou shalt make sure your changes art reversible. Possibly by having separate commits for each piece of the project that is owned by a different author.
  • Thou shalt not update critical pieces of thy project that are tied to a specific setup. Kind of an off the cuff unrelated item, but next time I have someone update the friggin project file with their own heavily personal paths, I’ll ‘git rm -rf’ everything. Be warned.

I know it sounds like a rant from a totally pissed lunatic, but beyond the anger, I actually believe these are sensible (and scalable, even if you have different layers of ownership) rules that would make everybody’s life better if thoroughly applied.

Feel free to add your own in the comments.


[MeatSpace] Why We Won’t Get Rid Of Hardware-Minded Programmers Anytime Soon

The real world can be tough. Your magnificent app passed all the automatic testing in your nice development environment with flying colors? And now that it’s shipped, bug reports regarding code you were sure couldn’t fail are coming in? Welcome to meatspace.

One of the great things mobile development has brought back from the dead, is constraints.

Back when I started, in the glorious time of Mac OS Classic, processors could only go so far, you had a single core, and limited memory. That meant the UI could stutter and die under heavy load, and that you could run out of memory, forcing you to free some, or crash.

The predominant attitude when I taught was “who cares if some users don’t have enough RAM? next year, or 2 years from now, they will all have doubled their specs, we’re fine”. Which at the time was somewhat true, if a bit optimistic. Nowadays, on our computers at least, we do have almost infinite virtual memory, making RAM preservation a bonus, something “elegant” to do when releasing an app. As an example, I have 3 tabs open in Safari, totaling with its helpers a magnificent 400MB of used memory. That’s one quarter of the “standard” 2GB we had only a few years ago. And, the quarter of what we have today on high-end phones. 3 tabs. 150MB per tab. Except it’s not true. Virtual memory has to be shuffled around, making every application, including your own slow.

But, I hear someone shout, we do a lot less on our phones! Really? Don’t you think that having apps like Facebook, always reacting to incoming messages, or Twitter, streaming in the background need some RAM to function? It is so easy to forget your app isn’t running all alone on your phone isn’t it? That’s why I was shocked to discover that “killing apps” isn’t a power feature at all, it’s a standard one. I saw a young woman doing it in the subway and straight up asked here why she was. She told me it made her phone faster. When I asked her why, she answered she wasn’t technically oriented, but that she guessed it limited the number of things her phone was trying to do at the same time, maybe?

Again, it is common knowledge at the base user level that killing apps isn’t a thing you do once a year to fix a nasty glitch, but something you do on an hourly basis so that your phone doesn’t heat up, slow down, or eat its battery. Back in the day, I had trouble explaining to my dad he had to quit his mac applications if he wasn’t using them. Now, maybe he will tell me he kills phone apps every hour to make his device work better.

So, ok, sure, the mobile hardware is following a similar curve the computer was in the nineties and the naughties, but just like the computer curve did, the mobile curve will plateau. And your app could be running on a 3 years-old phone that has half the RAM and three times less CPU power than the fancy new one you are developing on.

A few things to remember when building your next awesome app:

  • use system frameworks as much as possible for your animations. They are built to skip frames in case of intensive use, and to coalesce changes to avoid a lot of graphical commands to the GPU
  • queue your network commands. Run one or two at maximum speed rather than 20 at slow as hell speed. Worst comes to worst, you can pause your queue and resume commands when the CPU grants you some time
  • in the same vein, don’t assume everyone is on ultra fast LTE, with the latest phone, and a full battery. Check for that, pause your queues when you don’t have a good enough network, and resume later. Bonus point to people dumping on disk in case of app termination
  • Don’t immediately compute a ton of stuff once you receive a new piece of data. Redesigning the whole screen, or database, because one letter has changed? what’s that? 1967?

[Xcode] Broken IPA Generation

As of Xcode 6.0.1, you can only generate an IPA with a certificate/provisionning profile pair that matches a team you are part of (it offers only choices present in your Accounts preference pane).

Before ranting about why this this is stupid as hell, here’s a workaround:

xcrun -sdk iphoneos PackageApplication [path to the .app] -v -o [path to the ipa] --embed ~/Library/MobileDevice/Provisioning\ Profiles/[profile to use] --sign "[matching developer NAME*]"

NAME is the name that appears in the popup menu in your xcode build settings, not its ID

After a somewhat lively discussion on Twitter about that, two things:

  • I know Apple would prefer that developers are organized in teams managed on their servers. It’s just not practical for a lot of them, and there’s even a few good reasons not to go that way
  • It’s stupid to have that drastic a change, when 3 weeks ago, the official way of having a third-party developer generate IPAs for your company was to give him a p12 and a .mobileprovision and let him do his thing, and to not warn people about the change

For those of you who don’t know how development of a mobile application works, yet, here’s a quick run down.

A customer contacts me for a development. We agree on a timeframe and a price. I write the code, provide them from time to time with testable betas. When we agree it’s finished, I give them the final IPA for putting on the store and we call it a day.

Providing betas and giving an IPA for the App Store work exactly the same: a binary is produced, which is put in an IPA (kind of installer package for iOS), then that IPA is signed, and transmitted. On the other end of the wire (be it the customer or the App Store), the IPA is decompressed, the signature checked for validity (by app ID, device, and status of the apple account), and the app can be run or put on sale.

In that scenario, if I use my certificate, I have to enter the device IDs the customer will test the app on, of which my developer account allows for 100, in total. So if I have 10 customers with 10 devices a year, I can’t work anymore. So, most of the time, the customer has to provide the relevant information for me to give access to the betas, and of course, since they’re releasing it under their own name, the relevant information to produce the final version, which is a different pair of keys.

So far, so good, all they had to do up until now was give me a couple of p12 (key archives) and the corresponding profiles, and manage themselves the test devices, the release, etc.
It allows whoever’s in charge to retain access and knowledge about what the company is doing. Does that person want me to see they are also working on a concurrent product to something I’m doing for somebody else? Of course not. And there’s no reason to give me that kind of access. Oh and if the customer wants to prevent me from using that certificate again, all they have to do is revoke it.

The new way of doing things is to have the customer invite the developer in the team (in the Apple sense of the term), which gives the developer access to every piece of information under the sun (even when we can’t use it directly).

This is part of an ongoing cycle of making life difficult for contractors. We always have to find workarounds. The idea that almost every ios/mac developer out there is writing code for the structure they belong to, who will then release it in their own name for the general public is ludicrous. It hinges on something that has been gnawing at me for years: the idea that code and binary are the same thing, and is what I’m selling.

That idea is false. When you get Unity3D for your game development, you DO NOT GET THE CODE. For Pete’s sake, we don’t get the code of the OS we are developing on! The idea that when a developer is hired, the customer automatically owns the code is one of the many fallacies I have to deal with on a monthly basis. You hire a developer for his/her expertise first, and foremost. It might be then applied to internal code, which the dev won’t own in the end anyways, or to a newly minted piece of code which might or might not be given with the ability to use said code as part of something that has value. It is a separate item on the negotiation list.

I might delve into the pros and the cons of giving out your source code with the binary in a later post, but let’s get back on topic.

If, like me, you don’t always give the code with the binary to the customer, you’re screwed. Of course they won’t give you access to their company’s secrets by adding you on the team, if they don’t want to. And, obviously, you can’t release the binary under your own name for a customer who wants an app.

Please give me back a way to sign IPAs for customers, directly from my IDE.

Thank you, and sorry for ranting.