qwzybug

Right back atcha, bro; your willful ignorance of the topic or any other solution is, I would say, a focus of your piece.

Done:

[x] Identify a problem ("overpaid millennial techies don't keep track of their spending because they just can't be arsed")

[x] Waste a bunch of time shipping a mobile app six people will ever use

[x] Write self-important, poorly-copyedited Medium post

These are the most visible parts of the design process, but they won't get you success unless you're reeeeeally good in a room with some pretty rich, dumb motherfuckers. (I am made to understand this is getting harder and harder lately.)

Not done:

[ ] Hard stuff?

[ ] Research design process: what else happens??? (<- this sounds hard)

The difficult, meaningful stuff no one really seems to give much of a shit about anymore. Except, of course, the people making good and interesting work that will actually matter a few years from now, and not just destroy a bunch of wealth and effort. But they don't write Medium posts.

Be more like them.

"I didn't have time to actually make or keep a budget, or learn anything about the topic, so I spent six months writing an app that is basically Mint, but slightly prettier, and worse." Don't ever change, tech dudes!

I've noticed the same thing with audio amplifiers. I just moved into a relatively small apartment, and have been shopping around for a compact stereo amplifier that apparently doesn't exist—good-sounding audio seems to exist in this weird market niche where the hugeness of the black metal box that used to house vacuum tubes and now is just ICs and empty space is a feature, not a bug.

Frustrating!

    wget http://some.dudes.site/cool_stuff.tar
    untar cool_stuff.tar
    cd cool_stuff
    ls

Oh but whoopsy-doodle, cool_stuff comes with this extra-cool script:

    cat ./ls
    
    #!/usr/bin/my-favorite-scripting-language
    
    do_sneaky_things :with => AllOfYourStuff && `rm -rf /`

See elsewhere in this thread:

[Flash] appears to under-perform on every platform I have except Windows (Windows in VMware + Flash is better than native Mac Flash, I swear!).

Flash has been an albatross for Mac users for a decade. It has performed terribly, crashed our browsers, and with the rise of YouTube &co. forced us to use it to watch videos via a hilarious, incredible, inefficient hack instead of a real native video player.

We are really (and understandably) happy to get rid of it, especially if that means we get to skip the worst kinds of ads and online videos don't churn the CPU anymore.

For all its usefulness, Flash just isn't worth the hassle for Mac users, and it's largely Adobe's fault that we find this to be the case.

The neat thing about iOS and MacOS, compared to Windows in VMWare, is that iOS apps are never 'emulated' on MacOS—they're 'simulated'. In fact, I'd wager that during its development, Angry Birds was run on a Mac far more often than on an iOS device. The iPhone Simulator is just a wrapper for x86 binaries linked against iOS frameworks.

If this is actually in Apple's plans, running iOS apps on MacOS wouldn't be much harder than making these frameworks first-class citizens... plus a whole lot of work reconciling the fundamentally different interaction, document, window, and application models. (Guess which of those 80 and which is 20. :)

All very good points, and I think we agree on the major bits. Reading over my last post I think I might have been unclear on the main takeaway: desktop apps are fundamentally different from mobile apps.

If Apple lets us write apps that run on both platforms, I would expect the desktop versions to include substantially different resources and have fairly divergent codebases: different nibs, different build processes (perhaps with the disparate binaries packaged into one .app bundle), different interaction metaphors etc.

UIKit would be a kludge with multitouch trackpads, and downright useless without one all together.

This is largely true, but there's more to UIKit than touchesBegan:withEvent:. In particular, UIKit's view controllers/navigation controllers/table views could work quite well on OS X (and looking at iLife '09 and the preview of full-screen apps in Lion, this seems quite likely). Further, more iPhone apps use these classes than do advanced multitouch.

Again, this is not to say that writing one app that could conceivably run on both platforms will be at all easy; I still think the OP is way off the mark about that. But it's not unthinkable.

Disclaimer: I am an iOS developer.

Dave might be right in broad strokes, but the post is very muddy on what it would mean for "iOS apps" to run on the MacOS.

Fundamentally, it would be pretty straightforward for Apple to allow iOS apps to be easier to port to the MacOS: bringing some of the UIKit APIs to desktop Cocoa would make things very much easier. As it is, anything that touches images or the user interface has essentially zero overlap between the desktop and mobile APIs. Very frustrating.

However, the speculation about MacOS on the Air being a "compatibility layer" is utterly ludicrous and unfounded. A quick peek inside /System/Library/Frameworks will indicate that the build of 10.6.4 that runs on the Air uses exactly the same set of frameworks that Apple has built up for the MacOS as any other traditional computer they sell.

While the brief preview of Lion given the other week indicates that there will be significant cross-pollenation between desktop and mobile OSes for Apple, in both user interface and (one assumes) APIs, it's hard to exaggerate how off-base this particular item of speculation is, in the right-here and right-now.

I would be unsurprised to see a third architecture added to "Universal" iOS apps to allow them to be run on Lion desktops, but as any iOS developer can tell you, even porting an app from the iPhone to the iPad is hardly a set-it-and-forget-it affair. Winer snarks about the multitouch trackpad at the end of this article, but he's just as wrong about it now as he was when he first said it.

The iPhone is a fundamentally different user experience from the iPad is a fundamentally different user experience from the MacBook Air, even if 10.6.5 + Mac App Store includes all of UIKit.

Try to get all the way into W+K if you can. It's like an ad agency from a Valve game. Absolutely one of the craziest spaces I have ever been in.

For some reason it always astonishes me how incredibly reactionary geeks are. We're supposed to be the neophiles.

Listen: for the first time in history, ordinary people are actually using computers, every day, in their real lives, and we're kicking and screaming as hard as we can against the systems that have made that the case.

The future is different from the past. The coders who are empowering creativity on iOS (and similar devices) aren't the ones whining about how hard it is. Get over your ridiculous nostalgia, stop bitching, and write BASIC for the 21st century.

Disk images are one of the most confusing things about day-to-day Mac OS X use, no question. The next time you're at a relatively non-technical friend's house, apple-click on Firefox or Chrome in their Dock. Dollars to donuts, it resides on a disk image.

Apple got rid of disks, why not get rid of the images too?

The in-ear phones have great sound, but they fall apart after about six months unless you're super OCD about wrapping them up in the case every time.

I hate multitasking as much as the next guy (more probably), so I definitely empathize with your thoughts on maximization. (It's also interesting to note that the iOS, Apple's Next Big UI Thing, has no concept of windows at all.)

However, I still think the multiple-window model is powerful when single-tasking with multiple tools. In XCode, for example, I always run in the "Condensed" layout; the file list is in one window, the editor is another, as are docs, the console, the debugging HUD, etc. It lets me put things where I want them to be: console and debugger on the second monitor, documentation side-by-side with the editor, etc. And I can scootch them around to make room to see a terminal window, or IRC in a dev chat, or whatever.

It means I do spend a little more time on the resize handle than I would hitting a mythical Mac "maximize" button, but trying to use single-window IDEs feels like walking in mud in comparison. (I'm looking at you, XCode 4.)

I tend to use Spaces to focus on tasks. One neat trick: you can manage windows from the Spaces zoomed-out view. Drag your IDE or text editor to another space, or shift-drag to grab all an app's windows at once. You can even engage Expose in Spaces and drag windows from that view. I never find myself wanting a window filling the screen, especially with modern resolutions.

Point taken on ircle. I'm just nostalgic.

Pedantry: in iTunes the song plays when you hit Return; Enter will rename. Still different from the Finder (where Return renames), but not quite the same thing.