Why I Develop For The Mac
evanmiller.org
evanmiller.org
"Many developers assume that everyone wants their data to be “in the cloud”, but that's actually not true for a lot of my customers. Professional researchers often sign agreements in their children's blood stating that their data will be stored on an encrypted disk, won't leave their laptop, and will be destroyed when the research project is completed. “The cloud” is the last place they want their data to go."
There are so many great note taking and productivity application that I just can't use because the majority of my notes are of a confidential nature. If my company provided macbook where to be compromised I would not be held liable, however if my personal dropbox or evernote account where compromised I would be held accountable.
But what advantage does that offer over a native application? You’d then need a ‘native’ web server and would still rely on the local browser in a way that opens you up to more incompatibilities than just using the native interface framework?
An interesting usecase would be a LAN-local server, which would (with server-side data processing) avoid the slow uploading of data over the internet and could still utilise native computation speeds on the server.
What I would like is a home cloud server which would handle all the services I could get from the cloud with explicit sharing with chosen people (e.g. my family).
If you plug together a handful of off the shelf Amazon components, slap a label on it, and open the doors, perhaps that is rightly called a "cloud" service ... the end provider has no accountability to you (or your users) and you have no idea what's going on behind the curtain. It's all just magic happening many layers of abstraction away.
But if you build systems, own the platform, write the architecture and provide something that you understand and have accountability for, end to end, I think it can satisfy the skeptics (of which I am one).
So in this case, the researcher that can't store the documents on dropbox ... hopefully he could upload them with duplicity to an online storage platform that was built and run like this[1].
And I hope that this would be possible because such a distinction could be made ...
If you're ok with relying on obscurity, you already have it - you are one person among billions on this planet. Who else cares about your photos?
http://www.synology.com/dsm/home_file_sharing_cloud_station....
Maximum capacity is 96T, that should be enough for most home servers.
http://www.kickstarter.com/projects/transporterguy/transport...
http://www.kickstarter.com/projects/clintgc/space-monkey-tak...
(But it's pretty cool. I'm an alpha user.)
A lot of the time, these requirements are more about auditing and liability than about technical security measures.
1. even in Seattle, internet response time is erratic. Delays anywhere from a second to a couple minutes is commonplace. Using an app requiring constant traffic over the internet is quite unpleasant.
2. The backup problem. If my cloud account "goes dark" for whatever reason, I'm dead in the water, and I'm helpless to fix it.
3. I simply won't use a cloud solution that doesn't encrypt the data on my machine before sending it to the cloud server. Encrypting it after it gets to the cloud server is unacceptable. I currently use Jungledisk for backups on Amazon's cloud service because it does encryption locally.
[1] http://www.daemonology.net/blog/2011-06-03-insecurity-in-the... and its discussion here: https://news.ycombinator.com/item?id=2616634
[2] http://push.cx/2011/retracting-my-jungledisk-recommendation
Isn't the cloud part of your back-up strategy? For example, I use OneNote for all of my notes. It syncs the notes on my PC to the cloud. As long as I'm connected, I have a backup online.
Changes also sync to my other computers when they're online.
Additionally, the notebooks are included in the local data backups we make (in our case off-sited to our ISP).
Sensitive stuff is encrypted in TrueCrypt, and the TrueCrypt volume is stored on DropBox. MI5/CIA could probably break the encryption, but there are easier ways for them to get at it.. http://xkcd.com/538/
On the other hand data on an encrypted disk is not exactly the same thing. It must be made available to the OS whenever the user is logged in. Any breach in security say from an email attachment or malicious website would expose its unencrypted contents.
I wonder what the required policy is for backups? Can they be stored on servers if encrypted? Remote servers?
Back when I was part of a EU research project, we could not use Skype, DimDim or any other video-conference platform because a lot of stuff we worked was protected as the author comments under a lot of privacy contracts.
I consider this a bit of a frustrating pseudo-myth. It's true canvas is slow compared to lots of native drawing, but its usually presented as a false equivalency issue. Canvas didn't set out to replace native drawing of hand-crafted OpenCL. It's an alternative to cross-platform graphics on the web, where you get Canvas or you get Flash (Or SVG or hobbling together colored DOM elements to animate while crying and eating ice-cream out of a gallon tub. We've been there. Don't lie.).
What's worse, looking at the videos demoing his Mac app[1], they don't even look like they'd need canvas levels of performance. They look like they'd work just fine in SVG. What's wrong in this case with the very good performance across many platforms (even tablets) of the SVG-backed RaphaelJS?[2]
Unless his app can do things he'd rather not demo, I'm guessing this post is moreso post-hoc rationalization of picking Mac as his preferred development platform. At the risk of being a bit rude, it's worth noting that he doesn't bother with all Desktops, just Mac, which causes further suspicion that this is really just a rationalization piece and not about performance.
(Unrelated to the post at hand, this canvas pseudo-myth also upsets me because I spend big chunks of free time helping people with their canvas work, and its almost always an issue on the programmer's part. This is fine, I've never fault a programmer for writing less-than-optimal code, but often programmers tend to contribute their voices to the chorus of "Canvas is slow", regardless of looking for fault prior to their declaration.)
So I attempted to determine the accuracy of this claim. I ran a benchmark from Kevin Roast [1] who seems to author a lot of Canvas demos. For each of the 8 tests in his benchmark, I recorded the FPS reading that I saw that was the lowest (e.g., framerate dropped to X at some point during the 5-second test).
Mac iPad
20fps 16fps
29fps 18fps
30fps 21fps
30fps 30fps
28fps 6fps
29fps 18fps
29fps 7fps
12fps 30fps
mean_mac = 25.875, median_mac = 29 mean_ipad = 18.25, median_ipad = 18
On the Mac side, I can see both sides of the issue. Arguably 26-29fps in a wide variety of situations is good enough for a wide variety of applications. At the same time, I can understand the author really wanting to blow past 29fps.
On the iPad side, the issue is more clear. I think most people would say that 18fps is unacceptable for a drawing application.
(If these numbers are contributing to the "pseudo-myth" of slow Canvas performance, please point me to a reasonable benchmark. This one is just the most comprehensive one that I found.)
> At the risk of being a bit rude, it's worth noting that he doesn't bother with all Desktops, just Mac, which causes further suspicion that this is really just a rationalization piece and not about performance.
He addresses the choice of the Mac platform in some detail in the "Drawbacks" and "Conclusions" section of the post. At the risk of being a bit rude, it's poor form to dismiss someone's reasoning as a "rationalization" without addressing the reasoning on the merits. To the extent that his choice of Mac over Windows et al is specious, it is not a claim that is supported by your comment.
In the test you quoted the goal is to stress it until it could only handle 30fps (it says so on the page), so you necessarily must see 30fps for the test to go on to the next one. That is why your median score on the Mac is 29fps, because it degrades smoothly on the desktop compared to a mobile device.
If you want to see many devices peg 60fps on the canvas (the rate imposed by requestAnimationFrame), you can use a demo like MS' Fish one.[1] Your Mac ought to get 60fps for 1000 fish on a 1920 x 1075 canvas with no sweat. This is not a very interesting test, and I don't know what it will look like on an iPad, but it more than enough accounts for any animation you might see in a mapping application.
[1] http://ie.microsoft.com/testdrive/performance/fishietank/
I just checked, and indeed, my new MacBook Air with external display ran it just fine at 60fps. My 3 year old Mac mini handled 45fps. My iPad 4 managed to crank out 25fps in a 981x644 window.
This is incorrect. Firefox and Safari use Core Graphics (Quartz) just as Mac native apps do. Things like lines and circles go through the exact same SSE-accelerated routines. I don't know off the top of my head whether Chrome uses Skia or Core Graphics on the Mac, but either way, its blitting routines use SSE optimizations as well.
You succeeded in picking out a minor technical inaccuracy, but not in addressing the point the author was making about rendering performance.
It does, but unfortunately neither Webkit nor Gecko respect this. Take a PNG with an alpha channel and draw it to a canvas over a white div then read back the pixels; you get the pixels premultiplied by the white behind it. Same with other backing colors. There are cases where it won't premultiply, but unfortunately they're a minority.
(The reason I ran across this particular case is that I use PNGs to compress data, and using the alpha channel to store data is impossible because of the premultiplication.)
I think John Gruber summarized it nicely when he said: "Facebook, bless them, has it right. What's great about the web is ubiquitous network availability, not running within a browser tab. Websites are just services, and what you see in a browser tab is merely one possible interface to that service. The best possible interface to that service is often, if not usually, going to be a native app, not a web app."[1]
1. http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...
Sencha's little demonstration was the very definition of "bending over backwards".
Facebook is, IMO, one of the gold standards now for large-scale iOS app building. I had the pleasure of hearing one of their people speak about this a few weeks ago and they're very much at the forefront of iOS engineering.
http://www.tuaw.com/2013/03/05/whys-facebooks-app-so-much-be...
Plus, the Facebook app is way different now. I don't see how it'd be possible for them to implement web-based chat heads without killing the performance (even on my iPad 3 it isn't 100% smooth). Lots of times these clever design concepts cannot be implemented on the web because of its relative performance drawback.
Web does not mean ubiquitous network availability. It's a turn of phrase that only seems to originate from Silicon Valley and Redmond. When I get on the London Underground my network is gone. When I drive from Cape Town to Hout Bay my network disappears. When I go into my favourite coffee shop in Berlin my network disappears.
If an app (Evernote, for example) relies on a non- store-and-forward network connection to hook me up with my data it gets uninstalled. I can't use Trello for the same reason. When I need my data I need my data.
At least native apps can fall-back seamlessly.
> his own comfort and expertise with it - which is fine, of
> course. With the advancements made in web tech today
> I'm going to take a wild stab at the primary reason he develops on the Mac is his own comfort and expertise with it (...)
This to me reads as "I'm not going to put much thought into this, but it sounds like he is just ignorant."
Maybe you didn't intend it that way, but that's how it read to me.
It's not hard to do responsive design. Yes, in iOS world you can still hard code 5 layouts if you want. Those of us that have also done Android design work understand why that's untenable moving forward. I'll take relative layouts, etc and be very happy with Bootstrap/Foundation.
I don't know if responsive design is "hard" or not, but I observe that on the web, fixed widths are still incredibly common, and even major sites break easily. I visit Google, and if my window size is not at least one thousand pixels, the Sign In button is clipped and not initially visible. This would simply be considered a bug in a desktop app.
Besides, I always thought that layout was one of the weakest parts of HTML and CSS - witness the endless parade of hacks to achieve equal height columns.
[1] http://bethesignal.org/wp-content/uploads/2009/06/css-is-awe...
It gets better with some of the CSS3 layouts which more closely mirror what's ben available in the desktop world for ages, but using those is just a recipe for »Your site looks like crap on my browser« mails because they're not standardised yet or not yet widely-implemented (or your target audience uses something else than the bleeding-edge version).
I wasn't implying desktop designers hard code everything -- but in fact many of them do or make assumptions that the app will NEVER be used on anything smaller than even the absurdly small 800x600. We're talking about mobile apps, responsiveness, the cost/benefit of targetting multiple devices with one app vs six native apps.
If you target multiple platforms with one app, you get an app that works from OK to poorly on lots of platforms. Look at Light Table as an example: done entirely via web technologies, easy to port everywhere, but feels incredibly alien and _wrong_ on my Mac. (No offense Chris!)
Compare to Sublime Text 2, which to my understanding has lots of platform-specific code to make it feel native on each platform, but also a shared core (using Cairo, etc). So "six native apps" need not cost anywhere near six times a single native app.
So in the end, the cost of targeting multiple platforms with a single app is surely lower than targeting each platform individually, but that's just a classic cost/quality tradeoff - the web limits your polish. And what good is having your app on multiple platforms if it's inferior to native alternatives on all of them? I know as a Mac user, I'll pick the Mac app that feels like a Mac app every time.
I think the problem is the youth of today doesn't know anything other than web development, so they are full of false assumptions.
(disclaimer: I purchased Wizard a few months ago and have been exceptionally happy with it -- it's a brilliant product)
Yup. New Zealand's internet speeds are just abysmal. On behalf of kiwis everywhere, can I ask that you all stop writing your own wrappers for web based videos? Instead, upload your videos to YouTube and embed that on your site. Their buffering is orders of magnitude better than some of the half baked crap I see from other people, probably because streaming video is YouTube's core business so they've focused a lot of time and attention on getting it right. If you live in urban parts of United States or Asia it's not a problem you'd notice, but for the rest of us it's a daily nuisance.
The proper way is to have desktop applications that take proper advantage of the hardware and operating system integration and use the network for communication.
Leave the browser for the documents. No need for browser compatibility headaches or JavaScript/CSS/HTML hacks.
Just use your favourite programming language and take advantage of the OS capabilities to full extent.
I work for a consulting company which does all kind of projects, and I jump from joy every time I get to chose a native project instead of a web one.
It all depends on the market you are aiming for.
Debugging CSS is much less fun than using a proven multiplatform C++ toolkit. Only when node.js got popular I could write the ever reliable callbacks in my web code, while I use them all the time in C++.
But of course there are more people who can write web apps than people who can add this symbol at the end of the line -> ;
There are many other areas when desktop is still the way to go.
Try running a disassembler on any compiled graphic applications of the last 10 years on any platform and you'll see SSE instructions.
That's what we call throwing the baby out with the bath water. What's wrong with using an orthographic frustrum?
Wolfire have written a very good blog post about the issues with text rendering and OpenGL. http://blog.wolfire.com/2013/03/High-quality-text-rendering
Imagine, 10% of desktops have Mac OS, of that only 20% will buy my application; that's a very small user base.
Are we getting so disillusioned that we consider to be "such a small potential userbase"?
20% of 75 million is 15 million. 15 million copies of any paid app is huge.
Also, let’s not forget that Mac sales has been growing for years, while the PC market as a whole has been shrinking. Today, there are 3 times as many Mac users than 5 years a go.
Half of all new Macs are sold to people who are ‘new to Mac’[1]. Even the people who buy a replacement for their old Mac will often find other uses for that old Mac or they will sell it or give it away.
One year a go, Mac install base was 66 million. Since then, 17 million Macs have been sold. 8.5 million of those are sold to people who never owned a Mac before. Let’s imagine that all the remaining 8.5 million units are bought by existing Mac users, and that half of them are bought because the old Macs died. That gives us a new total of 78.75 million.
[1] http://www.forbes.com/sites/carminegallo/2012/07/25/7-sure-f...
GP is not an exemplar of the 1% fallacy. GGP asserted that their product would have a 20% install base, so GP used that number.
Personally, I can barely stand web applications, I want my computer to move as fast or faster than I think.
Plus, people are selling desktop applications since the dawn of home computing, nothing new there.
It is up to you to somehow transform text into 3D graphics operations.
I think Terra would give you a run for your money:
http://theory.stanford.edu/~aiken/publications/papers/pldi13...
From the paper:
> Our Terra-based auto- tuner for BLAS routines performs within 20% of ATLAS, and our DSL for stencil computations runs 2.3x faster than hand-written C.
See also:
That said, he points out performance, which is a pretty poor reason nowadays.
Thoughtful blog post as usual.
I recently (today) stopped to try to make some simple ogre3d application because somehow xcode can't manage permissions to create a file somewhere.
I had already searched and found people with the same problems, but it boils down to hardship between xcode and cross-platform build software like cmake and others.
I don't want to bash apple, but it feels awkward to be a dev and watching apple digging up their NS tech to put in everyone's mouth, even if there are business with big working c++ codebases. Being incompatible with the competition is still a strategy, even if apple use unix-flavored stuff.
Source: http://www.nngroup.com/articles/response-times-3-important-l...
And I personally think he's (shmerl) right. Learning a couple almost completely redundant APIs, but each with it's own problems, gothas and plain stupid decisions is hardly a good thing.
Most users know so little about the UI of their computers that they don't know when to click the mouse once or twice.
They spend their day working on Windows, checkout Facebook on their iPhone on the way home, play a game on a Playstation then send some email using Gmail on Safari.
Then you have the major changes within operating systems over recent years, Windows Vista/7 and Windows 8 both introduced major UI changes as has OS/X.
Peoples interaction with computers has become much more diverse. Unless the UI is jarringly different they just aren't going to notice.
You have less of an excuse on the Mac, which has literally the best GUI API in Cocoa that anyone has ever invented.
Not so iron, if you have many platforms to manage. Usually it doesn't worth it to manage tons of separate toolkits for each platform, if there is no common abstraction at all. It's just too costly.
If your app looking like shit will cost you significant sales -- as is the case for most productivity and design apps -- then yes, you have to port the GUI bits to each and every toolkit you're using.
Firefox, LibreOffice, VirtualBox and etc. If you don't know how to make good GUI using generic toolkits it doesn't mean it's not possible.
Anyway, if you buy application for its "looks" - there is something seriously wrong already. It should look good, no doubt, but it should be functional first.
>as is the case for most productivity and design apps
Completely the opposite. They tend to provide completely custom, not native looking UIs, and therefore using cross platform toolkits for them only makes more sense.
And I wouldn't describe LibreOffice as "not looking (and running) like shit". Again, nobody on Mac actually uses it, and Windows has the real Office.
Prefixing names is just something no developer should be forced to do.
I hope with the work being done in clang for C++ modules, Objective-C gets some form of namespaces as well.
Any programming language will be awful for UIs, be it C++, Obj-C, Python or C#.
In Obj-C it's not unusual to have to mix in C. And sometimes the code I write is quite fragile due to the type system and not having some features available.
There’s a reason why there is Wolfram|Alpha and Mathematica.
As for the last statement, and much of the others, I'm not even sure what you're asking. If you want a nice syntax for it, then yeah, wait for the spec to be finished. Otherwise, you're probably implementing that logic yourself. The same as if you want a native app to pull in different assets (unless we're talking about UI assets and a sane OS, but still, it's not like that's a compelling lacking feature).
Look, I'd be happy to be wrong but there are half a dozen inaccuracies in this very article about what is possible with web technology and how browsers themselves work.
Am I suggesting Angry Birds in web tech (even though it's already been done): No. Am I suggesting that shit basic apps like Facebook, Twitter, Reddit, etc make more sense as simple, functional, accessible webapps? Absolutely.
1: https://www.facebook.com/notes/facebook-engineering/under-th...
For CRUD apps like Facebook, it's often easier to do them right as web apps, but a good native app developer with a good backend team should almost always be able to beat them.