Xcode Packaging

Speaking of packaging, a thing I hated in Xcode, which made me wish to be filled with nuclear fire, transformed into Godzilla, and stomp thru 1 Infinite Loop, was the package structure:

foo/
    foo/
        foo-Info.plist
        foo-Prefix.pch
        foo.entitlements
        all source, images, and config files in a single giant mess, regardless of "groups"
    foo.xcodeproj/
        foo.xcodeproj/
            project.pbxproj
        project.xcworkspace/
            contents.xcworkspacedata
            xcshareddata/
                foo.xccheckout
            xcuserdata/
                mdh.xcuserdatad/
                    UserInterfaceState.xcuserstate
                    WorkspaceSettings.xcsettings
                    xcschemes/
                        xcschememanagement.plist
        xcuserdata/
            mdh.xcuserdatad/
                xcdebugger/
                    Breakpoints_v2.xcbkptlist
                xcschemes/
                    foo debug.xcscheme
                    foo release.xcscheme
                    xcschememanagement.plist
    fooTests/
        more sources

Are you fucking kidding me?

Groups aren't folders, they're just keywords grouped together until Xcode decides to fuck you over and disorganize them. To fight the project dump dir, I'd make a group, then add a subfolder, edit the group to reference the folder, and then I could create files in their own nicely-organized subfolder. There is of course no automatic name sorting, because that's a developer convenience and Xcode hates developers.

Test code couldn't be in the same folder as the code it was testing. So you'd edit a file, then edit a test file WAY over in a different tree. Good luck knowing how much coverage you had.

I especially love how foo.xcodeproj/xcuserdata/ and foo.xcodeproj/project.xcworkspace/xcuserdata/ have duplicate structures for develop & run/debug modes, because obviously the runtime and debug teams are separate and hate each other.

Icon Composer

In their ongoing efforts to break Mac development tools, Apple disabled and destroyed the rather nice Icon Composer.app because there's nobody left in-house who could figure out how to generate @2x images (protip: you use double size and rename it!), and now you have to use command-line iconutil with a set of magic filenames and no help.

So I wrote a little shell util, icontool.zsh:

#!/bin/zsh
if [[ $# -ne 2 ]]; then
    echo "Usage: icontool INIMAGE.png OUTFILE.icns"
    exit 1
fi
WORKDIR=$TMP/icontool.iconset
rm -rf "$WORKDIR"
mkdir "$WORKDIR"
sips "$1" --resampleHeightWidth 1024 1024 --out "$WORKDIR/icon_512x512@2x.png"
sips "$1" --resampleHeightWidth 512 512 --out "$WORKDIR/icon_512x512.png"
cp "$WORKDIR/icon_512x512.png" "$WORKDIR/icon_256x256@2x.png"
sips "$1" --resampleHeightWidth 256 256 --out "$WORKDIR/icon_256x256.png"
cp "$WORKDIR/icon_256x256.png" "$WORKDIR/icon_128x128@2x.png"
sips "$1" --resampleHeightWidth 128 128 --out "$WORKDIR/icon_128x128.png"
sips "$1" --resampleHeightWidth 64 64 --out "$WORKDIR/icon_32x32@2x.png"
sips "$1" --resampleHeightWidth 32 32 --out "$WORKDIR/icon_32x32.png"
cp "$WORKDIR/icon_32x32.png" "$WORKDIR/icon_16x16@2x.png"
sips "$1" --resampleHeightWidth 16 16 --out "$WORKDIR/icon_16x16.png"
iconutil --convert icns "$WORKDIR" --output "$2"

Preferably feed it a 1024x1024 input image, it'll resize all the others; the small sizes might be blurry but it's good enough for most uses, and you can edit the contents of WORKDIR and run the iconutil line again if you need to.

Marzipan and Electron

Chris is missing the point of both technologies. And I'm sure not a brat Millennial.

Marzipan (candy frosting) is a legacy porting technology: Existing iOS apps can cost more to port to AppKit than they're worth, but may be worth something as a cheap Marzipan port. Nobody ports their iOS apps to tvOS or watchOS because it's not profitable, and everyone (in the first world with money) has an iPhone already.

I loved my UNIX® workstation Macs after suffering with Linux for a decade+, but Timmy Cook's Apple abandoned the Mac after Steve's death and Scott Forstall's firing. Anyone making new native Mac apps is in an abusive relationship: Apple does not love you, and does not care about the Mac.

I'd rather eat broken glass than run Linux again, and I have never and will never be a Windows weenie, but I'm not relying on Apple to support desktop developers ever again.

Apple's Mac apps have generally been shit for years now, because they won't spend the resources to develop & support their own stuff. iTunes is a bloated pile of crap, half-broken because it has to run on Windows, too; you don't like hybrid web apps? Everything except your library is web or XML rendering. Pages and Numbers were fast, minimally useful apps that got rewritten based on the iOS versions, and are just about useful for a memo or a chart, but not real work. Mail's a clusterfuck and not half as useful as when it supported more scripting and addons.

The new Mac commercials, first in years, show the broken-keyboard laptops and models they no longer make, nobody coding Mac apps, no desktop Macs. Where's that shiny "new" iMac Pro from last winter? Isn't that what a real musician would use? A near-blind photographer squints at a tiny Mac laptop instead of a giant 27" retina display?

This is how technical, developer-oriented Apple ads were in 2002:
apple_unix_ad-s

Electron and Node are the future (along with Elixir, Go, Rust, maybe others?). It's 100x faster and more fun (attach the FunMeter™ somewhere fun) to code in than Swift, you can use any good editor instead of fucking Xcode, do layout with HTML/CSS instead of the rotting corpse of Interface Builder trapped inside Xcode. And it's cross-platform; 95% of the users (even in the first world with money) don't run Mac, because Apple never updates the Macs, they failed utterly to follow-through with Macs behind iPhones. There's 20x bigger market potential.

The future is certainly not banging your head against the Swift and Xcode walls, just to make a pure Mac app nobody will see. You can't make fun of Electron's runtime, which needs Node and Chromium, if you use Swift, which has a giant runtime turd because their amateur hour C++ compiler nerds can't make a stable ABI. The Mac's only future source of native apps is Marzipan ports.

There can be performance problems in Electron, but Slack's an outlier at 196MB binary and devouring 1.2GB RAM(!!!); it's the bloated WalMart-shopping fat-ass of Electron apps. Discord is also Electron, it has a 136MB binary and uses 360MB RAM, and does more, faster and better than Slack. Atom is the original Electron, has a 541MB binary, and uses 600MB RAM, for an entire editor/IDE.

My game currently has a 139MB binary, and uses 200-300MB RAM when running. Comparing to a random casual game from my Steam library, Chainsaw Warrior (well, "casual"; I've only beaten it once on Easy). It's based on Unity (another VM!), has a 249MB binary, and uses 200MB RAM when running, plus Steam itself uses 130MB RAM (I may yet integrate Steam into mine, so that may even out). It doesn't seem excessive.

I can't compare my Swift game prototype from 3 years ago, because it was written in a version of Swift that doesn't compile in any Xcode that runs on current hardware & OS, and Xcode "helpfully" deleted the built binary; who needs working binaries, right? I might have an old Xcode on my old laptop? Maybe I could waste a couple days fixing the code by hand in current Xcode, if I hated myself or loved Timmy Cook's Apple that much?

New languages evolve fast, but I can run 20-year-old Javascript and it'll run thousands of times faster than it did in the '90s, because the language was improved with forwards-compatibility in mind, hardware caught up, and the newer VMs compile & run it faster. I can compile 30-year-old Objective-C, and it'll run.

We had something similar to web tech 20 years ago with desktop Java, but the convicted criminal organization Microsoft sabotaged it and made a shitty single-platform ripoff called C#. Viruses became a problem for applets, which had nothing to do with desktop Java, but killed Java deployment even before Oracle bought & ruined SUN. Android runs on another Java ripoff, but their dev tools and APIs are even shittier than Xcode or C#, and the users are poor, so why make anything for them? Server-side development in Java, Clojure, or Scala, running on the Java VM, is hidden away in a back room, and made as boring as possible.

So now we have to reinvent the runtime, this time with Node & Chromium. OK with me.

Learn2JS

I've updated the Learn2JS shell, which makes it easy to get started writing client-side Javascript.

  • Added eslint tags and an initial config, so you can check for errors while editing.
  • Switched from a Python web server to light-server on Node; even though the shell doesn't use Node directly, it seems more consistent.
  • Added Canvas class to simplify setting up and drawing on HTML canvas.

Any suggestions or feedback? I just use this myself to script things quickly, but I'm happy to enhance it into a better learning tool.

Tower of Babel

Ugly shit from my package.json:

 "scripts": {
    "start": "electron .",
    "build": "rm -rf build && babel app -d build/app && cp -R assets package.json build && cp app/*.html build/app && cd build && npm install --only=prod && cd ..",
    "dist-mac": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon.icns' --platform=darwin",
    "dist-linux": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon-256.png' --platform=linux",
    "dist-windows": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon.ico' --platform=win32",
    "dist-all": "npm run dist-mac && npm run dist-linux && npm run dist-windows",
    "dist-help": "electron-packager --help 2>&1 |less"
  },

So I wanted to filter my source through babel-minify.

Build out to a "build" dir… and everything breaks. Copy in assets, package, HTML files… "Missing module". Turns out known issue, closed but I don't see an actual solution: Nuking & reinstalling my node_modules did nothing, and I have latest stable versions (maybe "stable" is the problem?) of everything.

As a brute-force Hulk-smash solution, shoving that "npm install" in the build script works, and is easier than figuring out what I should change.

Xcode is Flawed

"So, yes, Xcode is flawed. But is it fundamentally flawed? Is there some core concept — its multi-paned single window UI, its scriptable build system, the nature of app bundles and code signing — that makes it impossible for Xcode to ever be good? I don’t believe anyone is making this argument. The closest you get to this is storyboard haters who build their UIs in code. I disagree with that camp, but even if I didn’t, that alone is not enough to relegate all of Xcode to junk status."
Chris Adamson about his new book, Xcode Treasures

I like @invalidname, but wow do we ever not agree about this. I diatribed a bit yesterday, but let's look at just these claims.

The build system is basically a shell script but with a custom editor that's harder to use than typing. Did you know that most programmers are pretty good at typing? Most of my projects, in fact, just had a shell script "phase", and then I'd write everything in bash (I hadn't switched to zsh yet). It is no better than an old-fashioned Makefile or nmake, and for many projects a build shell script is enough. But, sure, this isn't the worst thing in Xcode.

Code signing is Hell, and Xcode's original version on iPhone SDK launch was appallingly hard, but it worked. Now they've automated it, which means you have 512 bogus auto-generated configurations on your ADC profile, and if the signing server is down (which happens… well, it's not even two 9s of uptime…), you can't do anything until some hours later when Apple plugs the server back in. Entitlements and services you turn on/off can permanently burden your app's configuration, until you go to the website and houseclean all the junk configurations and make a new one with just what you need. And that'll get replaced with an auto-generated configuration again.

Xcode does have a dozen or so color themes now, but you can't change the UI chrome from generic Mac gray, so it'll always be unpleasant to view dark-background themes, you can't choose different icons, can't script the goddamned thing. Meanwhile, here's Atom's 7556 packages including 2579 themes, and you can just hack on all of the editor in JS & CSS, live-updating your own tools.

I quit using storyboards except for nearly-blank launch screens, and XIBs (NIBs! We called them NIBs!) except as maximized view holders, because the corpse of Interface Builder trapped in Xcode's belly punishes you for using them; if you touch anything, your autolayout constraints go crazy. And you can't delete constraints in the view where you edit them, only in the tree view which isn't even visible normally, and is organized totally differently from the editor on the right. After a few versions, Xcode just can't edit an old project's XIBs anymore, and then you're FUCKED. Have fun recreating that entire UI, OR you can put it in code. And if you're writing code, why not just leave the walled garden and write HTML/CSS/JS like I do?

The one-window thing doesn't bother me, but the lack of functioning tabs is infuriating and stupid. Open three files. In BBEdit, all three appear in the sidebar, and you can switch with the top-left file selector or the bottom-left list of "Currently Open Documents", or other navigations; I prefer tabs, but it's entirely acceptable. In Atom or AppCode, all three appear as tabs at the top of the editor pane, and you can drag to reorder the tabs as you like; each tab is a unique single view into that file. In Xcode, you can open them in separate windows, or in separate "tabs", but the same file can be open in multiple places, but if you close it in one, it closes in all of them. WHY WOULD YOU DO THAT? If you click a file in the tree view, it replaces the contents of the current tab/window, it doesn't just open it in a new tab. So the process is click, double-click to get a window, then on the first view hit back and hope it goes to the right file. Flames on the side of my face!

Snippets. OH NO, I had a PTSD flashback to Xcode's Snippets. You write a piece of text you want to reuse. Select the text and drag it onto the Snippet area; you can't right-click or menu it there. No, you clicked on the background, now it's deselected. You have to reselect, click on the stroke of a letter in the text. Maybe zoom the screen in with ctrl-mousewheel, now you must grab a SINGLE MOTHERFUCKING PIXEL!!! Calm, deep breaths… and drag it to the Snippet area. 😡🔪🔪🔪 In Atom, you either copy-paste it into a config file, or install snippet-generator-plus, select text and hit a key.

Xcode isn't just accidentally hateful and awful. It must be the work of a malevolent intelligence to be this horrible. I've found a recording of the original design meeting for Xcode.

Spend a few days working in an IDE that doesn't hate you like AM hates Humans, and you'd kill anyone who tried taking you back.

New Electron Dance

No, wait, that's the Neutron Dance, I get those confused.

Electron

Since abandoning any hope of the iOS App Store paying my bills, I've had to look back at the web or desktop. My current available time-at-computer and energy these days isn't sufficient for a day job or even contracts, much to everyone's dismay. So time for another hard look at the situation.

I like working on my Mac, but Mac isn't that big a market. I also want to ship on Windows (and Linux, I suppose). Objective-C is one of my favorite languages ever, Cocoa & UIKit (on iOS) were great APIs, AppKit on the Mac much less so, but since Apple's killed Obj-C and it's not portable, my happy years of typing [ ] are over.

WHAT HAVE YOU DONE?!

Swift might be the worst mental disorder to strike programmers in decades. Swift is orders of magnitude slower than Objective-C, crashes constantly, the moving-target "spec" creates incompatible changes every year, and because they're too stupid to standardize a binary interface, every program has a 20MB+ blob of Swift runtime. For a single-platform joke language perpetrated by a C++ bozo who fucked off after a year to play with cars. So I'm all too happy to say good riddance to that bullshit. I mean exactly this: If you're using Swift, you either don't know better (it's OK to say you don't know!), or are defrauding your employer for hours, or have something wrong inside.

13 years ago, Project Builder/Interface Builder was a pretty good dev toolkit since I could use a real editor (BBEdit) with it, but Xcode locked that out, and then as Apple sucked in more tools over time, it sucked harder and harder; I can't stand the rickety deathtrap these days. I was getting by in JetBrains' AppCode, but still had to use Xcode for Interface Builder (RIP) and to get builds onto a device half the time. Xcode is a crashy, substandard pile of shit with maybe the worst editor in any IDE in history. Syntax highlighting stops working at random, for most of a decade it has code-completed "nss" as "NSStreamDelegate" rather than the slightly more useful "NSString" (before that it couldn't code-complete at all!), I could go on for hours or days about how Xcode kicks you in the input/output ports every time.

And the worst part is you can't fix the fucking thing, no user-serviceable parts inside, Radar is a black hole, no scripting or plugins. Just bend over and take what Apple Developer gives you good and hard. It's kind of a relief that current Xcode doesn't run on the last stable MacOS version (Sierra).

I'll stick with BBEdit for text and Atom for code, thanks. If I'm angry at Atom I can fix it myself or file a publicly-trackable ticket; I'm rarely angry at BBEdit but I can ask Rich to fix it.

So I'm writing web-type software in Javascript, with Node or Electron behind it. Javascript aka ECMAScript has become a good language in the last 5-10 years, and the V8 runtime in Node/Electron runs close enough to native now for most needs. I love that I can just write UI in HTML again. No fucking around with Apple's bullshit of deprecating APIs out from under me (I "get" to rewrite alert/menu code again?!), or promising to support SpriteKit/SceneKit across iOS & Mac and then doing fuck-all on either. WebGL (or Three.js, anyway) isn't fast enough for complex scene-graphs, but 2D work in Canvas is mostly fine (and it gets better every year, instead of bit-rotting like unused S*Kit APIs). localstorage in a web page isn't enough for any real program, thus Node is needed to reach the filesystem.

I slander Swift for leaving a giant runtime turd in every program, but Electron's the same way: It has to contain a browser, Node, and system APIs. But I'm not at the mercy of Apple's marketing-driven dev tools.

Certain Mac nerds obsess about Purity of Essence, insisting that everyone should love Xcode, Swift, and AppKit, and that use of any other technology is an abomination to the end-users, whom they clearly love more than me. Can you hear that slurping sound? That's someone fellating Apple marketing. Roughly 4 billion more people are familiar with web pages and will find a web-like UI more comfortable.

I intend to keep up my experiments in Scheme and Pascal when I have time, I'd far rather have small, fast, native binaries on every platform, but shipping beats purity.

Progress is being made:

tile-20180426-map

tile-20180426-view

(the + road texture there will get replaced soonish)

Hypercard! The Software Tool of Tomorrow!

Encouraging people to write & submit new Hypercard stacks. Which, as a retro-tech challenge, I think is great. But. How about first having a decent modern Hypercard environment?

Why not? There's the classic John Gruber hit piece Why Hypercard Failed:

"Apple PR says it's a dead product so it doesn't matter if you like it! I like the Yankees who are also a bullshit PR project!"
—semantic analysis of all Gruber's posts produced this summary.

Stanislav (not a pleasant or generally useful person to me, but perhaps correct for once), had a different read of Why Hypercard Had to Die:

The reason for this is that HyperCard is an echo of a different world.  One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure.  A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone.  A world in which Apple’s walled garden aesthetic has no place.

Apple did have a near-Hypercard tool, Dashcode, which was slightly more technical but not much; it auto-generated placeholder functions and you'd fill them in with JS and use local storage as your database. They never fully supported it, killed it, and pushed Xcode instead, which is like giving kids a backfiring nailgun with no safety instead of a plastic hammer. Now they're ludicrously trying to teach kids BDSM Swift with the lldb debugger repackaged as "Playgrounds". I feel so sad for a kid whose first experience of programming is 100s of "unable to satisfy template constraint" errors; that's some hard unyielding playground equipment there.

There's a few modern variants, but nothing I know of that works:

  • Uli Kusterer's Stacksmith is unfinished, has no binary download or web site, and the build instructions are very pro-dev. Last time I tried it I couldn't get it to build, so…
  • SuperCard is $180/$280. Ha ha… uh, no.
  • HyperNext Studio is based on RealBASIC, and is free, but rarely updated. Does not run classic Hypercard stacks.

So everyone just gives up and uses emulation, because making a new Hypercard is impossible. If you're going to do that, do it the easy way: