Tag Archive for Apple

Mac Exodus Over?

Many commentators myself included have been making some hay out of the trend of developers and other pros moving away from Apple’s macOS in favor of various (usually Ubuntu) distributions of Linux. Vendors like Dell and System76 have seen gains in the professional workstation market against the less then well received MacBook Pro, but Apple is waking up and smelling the professional angst. Apple’s pronouncements in favor of professional computing on macOS and the promise of a revised MacBook Pro as well as a re-designed Mac Pro with a more “modular” design. We’re already seeing the so called Mac Exodus being blunted by Apple’s announcement. The questions becomes less a contest of Linux vs macOS quality and more a race against the inevitable tide of macOS’s professional resurgence. The overall goal for Dell and System76 should be to gain as much market share in the professional workstation space before Apple actually launches new hardware for that market. To that end, I’m going to play “CEO for a day” of Dell and System76 and game out a strategy for both of them respectively. I’m picking on these two firms, because I like them and also feel like they have the best shot of actually being successful.

Dell has money. Lots and lots of money. That’s great but also can lead to conservatism. Their success with the Sputnik project was one of the early and most successful ventures of a major desktop manufacturer into the Linux space. The product it produced – the XPS 13 Developer Edition – is still one of the most compelling Ubuntu laptops available. Dell needs to widen their Ubuntu product-line to include larger higher power models as well as something more akin to the MacBook Air. There will be an R&D / product development cost to this, but it’s going to be worth spending. The other key here is that Dell has a huge asset that System76 won’t – it controls its own production pipeline and has the manufacture of PCs down to a science. That should lead to better yield over competitors which at any reasonable volume means there are some margins to play with there. Dell should cut these margins on select base models of Ubuntu Linux workstations to the bone, nearly selling them at cost. This will make a dramatic cost comparison against Apple, given their already high prices and should also make Dell a very attractive supplier to creative agencies and the like as they look to cut costs in an increasingly competitive environment. Remember, the goal here is to gain market share fast and hopefully create career spanning Linux customers who otherwise would have gone to Apple.

System76 doesn’t have Dell money but it has something else focus. In many ways, they’re already taking the right steps to up their hardware game by moving away from Clevo and Sager hardware and toward producing their own, but more can be done. My expectation is that within the next eighteen months we are going to see more Apple quality hardware from them once their production lines and processes are fully up and running. Sadly, some of it is going to come at a greater cost than money. System76 has good relations with the Linux community and in particular the Ubuntu community. Canonical (the company behind Ubuntu), in what can be described charitably as a pivot toward reality, is dropping its Unity desktop user interface in favor of GNOME and seems to be more focused on IOT and “cloud computing” than the desktop. This makes sense, given that Canonical has limited resources and needs to make real money somehow, someday, someway. The folks at System76 who I’ve met and like very much need to find a way to show leadership in the community by guiding it into a direction that strengthens the Ubuntu desktop as the leading choice for professional workstations. The key here is to lead the community in the right direction but resist the temptation to commit too much of their own limited development resources to the effort. I know what I am suggesting is less being a good community citizen and more leveraging the community, but the reality is that the Linux community has been wasting development resources on alternatives to alternatives for things like package management and window managers — strong leadership could finally close some of these questions and focus the communities efforts.

This is a race against the clock and make no mistake, the window is closing quickly. If Linux workstation vendors such as Dell and System76 can’t make significant gains in market share quickly, then this whole “Mac Exodus” will be little more than a blip in the history of Apple’s domination of the modern professional workstation market. If you have any questions or comments, Tweet me and please checkout my Youtube channel where I offer Docker and DevOps tips.

Apps, Bots & Cloud Oh My!

Apps are the newest thing! Apps are dead, long live the cloud! The cloud is old hat, it’s all about bots and machine learning now! If you follow the tech press like I do, you might be led to think that we have come through some sort of supersonic period of technological creative destruction. It’s certainly true that we’ve seen a good deal of innovation, since the release of the iOS App Store in 2008, but it isn’t entirely accurate to draw a linear progression from apps all the way to bots in terms of direct technological replacement. Apps, Bots, and the Cloud each bring something to the modern way we approach software presently.

Apps: It’s hard to overstate how much Apple releasing the App Store changed standards in the wider software development industry in terms of user experience and visual design. Simply put, the popularity of iOS devices and apps raised the minimum bar for what is acceptable UI for even line of business applications and elevated the role of designers from Photoshop jockeys to having a head seat at the table on most development projects. Of course, with the good also comes bad – I’ve sat in more than one meeting at large enterprises where two designers derailed a meeting by having passionate but ultimately futile debates over Helvetica / Helvetica Neue and different shades of blue.

Bots: We are way too early in the technical life-cycle for bots to make any sweeping statements about their influence on software development as a whole, but if taken through the lens of apps, they can be seen as almost a reaction to the design-heavy / design-first focus that apps have taken. This can of course be seen in their minimal UI but also in the purity of their focus on functionality above all else. Ultimately, the promise of bots is to remove that one to one relationship between user actions and software actions that apps focus on; ideally, the bots of the future will predict what you want to suggest it to you / do it for you unlike apps where you have to initialize all actions. Unfortunately, bots are little more than glorified text interfaces running some clever scripting on the cloud. We’ll need to see some pretty significant advancement in bot functionality before they are really useful and so far the top tech vendors are taking radically different approaches:

  • Microsoft: Microsoft wants you to build bots on their Bot Framework and hopes that you’ll tightly integrate with Azure or at least Skype. While there are definitely problems with their approach (for instance splitting the community by having both a C# and JavaScript SDK) it is likely the most interesting for third party developers that want to develop on one of the big vendors’ tooling. Still, I’ve been burned by betting on new Mircosoft platforms before (I was one of the fools who made an investment in Windows 8 / RT) and I’ll need to see some re-assuring signs that Microsoft is going to continue active development and support on this before I jump in with both feet.
  • Facebook: Zuck and Co have one question for you – ‘what is it going to take get Facebook Messenger to be your default messaging platform?’ Facebook’s bot implementation is the most disappointing, since it’s one of the more interesting technically (their implementation of Wit.AI shows a lot of natural language processing potential) but is ultimately rendered useless (and frankly silly) by the huge strategy tax of being tightly coupled to Facebook.
  • Apple: What hasn’t been said about Siri that hasn’t been said about a 1992 Honda Civic? It’s relatively reliable if you know what it’s good for but lacks much of what would be desired at this point. WWDC is in couple of weeks and if Apple doesn’t deliver, then they’re likely to be an also ran in the bot space. My money is on some improvements to Siri, but Apple is likely to philosophically opposed to data mining and opening this sort of data to third party developers to make any bot framework they may provide anything more than a minor curiosity for the most hardcore of Apple loyalists. Apple will likely be left with little choice but to use it’s control of the iOS platform to either not allow competing bots on their platform or (far more likely) allow them but now allow them to integrate on a system level greatly degrading their usefulness to iOS users.
  • ‘Google:’ In place of a queen you will have a colorful gender-neutral ‘G’, not dark but productive and intuitive as the dawn All shall love Google and despair! Apologies to Tolkien but Google’s shown what is easily the most impressive bot to date and it’s name is simply Google. While it’s heartening to see such impressive predictive reasoning on a bot, it’s also a little scary in terms of the privacy implications and what it means for the greater bot ecosystem. Simply put, Google is in the best position to make the best bot of anyone in the industry and probably of anyone in the world in terms of targeting the mass-market consumer user-base. Ironically, Google’s aptitude in bots and related technologies will likely stifle innovation, since Google will be able to do a better job for cheaper (since they won’t charge at all) which will likely push many smaller potential competitors out of the market. At IO, they did say there’d be some sort of developer access, but right now they’re just making the best bot themselves and that’s a little disheartening as a small software vendor.

In part, it’s hard to see what bots really mean for the industry since there are different approaches being taken for them; for instance, they will likely be far more useful for Android users than for iOS users initially. Still, the common thread here is using personal and cohort data to predict what actions you might want to take via a simple voice or text interface.

The Cloud: Bots may be getting all the tech press but they’d be nowhere without the cloud. Or would they? What is the cloud anyway? Well, do you remember Thomas Watson of IBM fame who said: “I think there is a world market for only five computers.” On the face of it that’s laughable wrong but in more practical terms of what computers used to be defined as, he’s basically right. Instead of computers we call them “clouds” (think Azure, AWS, etc) and we are basically renting usage from them which will sound awfully familiar to anyone who has ever rented time on an mainframe in the 80s. Don’t get me wrong I am well documented as being bullish on cloud technologies (i.e. Docker) but to be honest the most interesting and impact-full innovation of the cloud for most people’s day to day use is the pricing model. That’s right. The main reason the cloud has had such a positive impact on the software development industry and the greater world as a whole is that it’s cheap. Cheap computing power allows even small companies (like mine) to invest and try new product ideas out with very little financial investment in infrastructure.

So we’ve taken a look at apps, bots, and the cloud but what is the point in all of this? Well, all of these things go together. You see bots aren’t replacing apps or the cloud. There is no linear progression. Bots and whatever come after them are and will likely continue to be built on the cloud and possibly viewed via or at least supplemented by traditional mobile apps. In fact, my bet is that for a few years the key to successful software products will be to blend all of these technologies together in natural ways.

Questions? Comments? Uncontrollable rage? Reach out to be on Twitter.

WWDC 2014 Predictions

WWDC 2014

Well, it is that time of year again – when the tech space goes crazy with Apple fever and starts to have dancing iTVs and iWatches in their heads. From the Apple developer perspective, this is (like the WWDC of 2012) being preceded by increasing frustrations from the community regarding Apple’s tools but more their practices – these complaints have been grumbling under the surface and indeed I’ve been at the forefront of sounding the alarm, but some fights have already been lost and if history is any indicator the prominent Apple devs will be placated by pretty much whatever they get on Monday. Still, to be fair, if Apple could address a few core areas of developer pain, then there would be legitimate cause to celebrate.

Contracts / Intents: Windows Phone and Android both have viable solutions to interapp communication that work very well for the developer communities on those platforms, the platform vendors, and of course the end user. iOS, however, has no real solution to this problem; I don’t consider and a reasonable person would probably agree that the current URL schemes tricks are all just really sloppy hacks that should never be shipped and no sane developer would use them by choice if there were a better alternative. There is no technical reason that this can’t be done and at this point Apple’s stubbornness is doing a huge disservice to the developer community and the end user.

App Test Distribution: One of the most annoying aspects of being an Apple developer is that whenever a customer or even a teammate gets a new iOS device, we have to go through the whole rigmarole of getting the devices UUID, adding the UUID to our developer portal, regenerating a provisioning profile, and making making a whole new binary just to get that one new device into the testing pool. This is absurd. Apple for good reasons wants to limit how apps are distributed outside of the App Store but at this point, there system is too much of an inconvenience to developers (a group I strongly feel is important to their long-term success) to be tolerated one day longer. There is some hope – a few months ago Apple purchased Testflight and that suggests that they intend to streamline the test distribution system.

Mac Mini Refresh: I’ve been careful not to put oo many consumer / new product requests in these sort of posts but I am willing to make an exception for the Mac Mini. Though the mini is probably the least sexy device that Apple sells, it is extremely important for the developer community at large, as a ton of little shops are almost 100% Mac Mini shops. At this point, it is pretty hard to justify the purchase of a Mini given how old the tech in the device is and the somewhat poor value proposition – at least compared with the iMac or an equivalent Windows PC.

That’s it. I don’t think these items are too crazy but am not so sure that we are going see anything of significance in any of these areas. My guess is that we will see nothing the way of interapp communication, a half step toward an easier test distribution, and little more than a spec bump or price drop on the Mini.

If you want to troll me when I inevitably proven wrong on Monday, then please follow me on Twitter.

Wither Webkit?

As you are probably aware Google has forked Webkit and will be calling their fork Blink. Google does not intend to re-merge with the main project at any point in the future and is signaling that they will be adding new features to their rendering engine. As a developer who often has to work on the web or mobile web this is very interesting but also a little concerning.


Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.


The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

Effects of App Store Distribution pt1

Those of you who follow me here or on Coder Radio or on any of the social networks that I frequent will know that I have been running a little experiment with my new Mac Application Code Journal; for those of you who randomly got here via a search or something like that, the experiment was trying to sell a consumer target Mac OS X application outside of the Mac App Store. No need to go into too much detail, since if you want more info you can go check out episode ten of Coder Radio, but the experiment did yield a result and a lot of feedback. Basically, there is ample evidence to support the idea that, in general, apps that target OS X will do better on the App Store than via direct sales.

As with the mobile space, I believe that increased reliance on app stores will have some considerable effects on the business of app development, the developers, and the apps themselves. So I am writing this three part series to discuss those issues and am taking something of novel approach (novel to me at least): I am going to look at this issues by comparing two very different apps Mars Edit, and my own Code Journal. I picked Mars Edit as a point of comparison because it is established and is in a different space than Code Journal, so there isn’t any risk of bias. Additionally, in many ways Mars Edit can be seen to represent the traditional Mac application model while Code Journal more closely resembles the single purpose “app ideal”.

The eight hundred pound gorilla in the room is app pricing. In general it is becoming increasingly hard to sell an app for more than a few dollars; some would argue that even getting the few dollars at all is really hard. Of course, there are exceptions to this, but those tend to be from either large game companies (think EA, Activision, etc) or from established Mac developers. An example of the latter would Daniel Jalkut’s Mars Edit, an app that is currently selling for $39.99 on the Mac App Store. Mars Edit’s success is a great story but also very atypical of pricing for productivity apps in the store and a lot of that may be due to Jalkut’s and the app’s cache’ in the Mac developer / enthusiast community; again for those who don’t know Jalkut was a former Apple engineer and has been fairly active in the community. Additionally, Mars Edit was successful long before Jalkut took it over; he actually bought the app from another developer in 2007.  A quick survey of competing apps in the same space on the store showed that most of Mars Edit’s competitors tend to be in the ten to fifteen dollar range and seem to have poorer placement in the store, which suggests weaker sales. One notable exception is the $39.99 MacJournal; Yes, there are of course other applications on the store that charge more, such as OmniGroup’s OmniPlan, but  we are looking at its competitors here.

What does this all mean? Honestly, Apple is the only who has the data to be able to truly say if the store if pushing prices down across the board. There certainly seems to be a correlation in applications being priced lower and the rise of the app store model, but there is an alternative argument (with an alternative villain) that could be made: free web apps may be forcing prices of native apps down by training consumers that a large class of applications should be free, such as Google Docs. Again, Apple is really the only who can disprove or prove the first point for sure and the web app debate is something for another day.

Check back soon for a look at what the App Store seems to be doing to independent software developers.

If you have some feedback please find me on Google+ or Twitter. Also, if you like my posts or work on Coder Radio, please consider purchasing Code Journal either from the Mac App Store or direct.

A Look at Control and the Mac App Store

Much like they have in the mobile space, Apple is leading the charge to commoditize software from independent developers, making it more affordable and convenient for users to purchase and keep up to date. The signs seem to suggest that this has on the whole been a boon for most developers but it has also put an unprecedented amount of control in the hands of Apple regarding what apps Mac developers create and what functionality they can and (more importantly) cannot have. Given that control, Apple has chosen to enforce a few policies that are not in the best interest of Mac developers: they refuse to support paid upgrades for large scale apps, enforce a rather rigid and restricting form of sandboxing, prevent developers from using some of the platforms newest and most interesting APIs on apps that are not distributed via the Mac App Store.

Developing software is difficult, time-consuming, and expensive. Traditionally, developers of large applications have used upgrade pricing schemes to maintain recurring revenues as a way to fund future development of their apps; an extreme example of this would the Adobe suite of tools.  Apple currently does not allow developers to charge for updates. Think about that for a second. Users are going to, as they have been trained to for years, expect  their apps to be kept up to date and, in some cases, provide increased functionality as time goes on. However, the current App Store model forces developers to either betray users’ expectations or somehow finance perpetual development of their apps on whatever one time cost they manage to charge on initial purchase; it should also be noted that apps on the Mac App Store have a tendency to be relatively low cost. Some have suggested that developers could take advantage of the Mac App Store’s in app purchasing APIs to make up the lost revenue. In some cases this might be a serviceable option but falls short of being a full replacement for true update pricing. The issue here is that this limitation discourages the continued development of large scale software for the ecosystem.

Security hasn’t been much of an issue for OS X historically. Despite what Apple fans would tell you, that has nothing to do with any sort of enhanced or inherit security on OS X. The truth is that OS X did not have a sufficient install base to make it an attractive target for malware authors. As Apple has been ever so eager to share, Mac sales are growing rapidly when compared to the overall PC industry. In short, OS X is becoming an increasingly attractive target for malware authors. Apple has responded swiftly to these increased threats in what is probably the most excessive heavy-handed PC security policy to date: sandboxing. If you are reading this, I assume that you already know what sandboxing is, so I won’t bore you by reproducing the definition here. In theory, sandboxing is a good way to make an operating system more secure, but in practice, it is more a restrictive mess than anything else. Basically, sandboxing does not provide enough benefits to be worth the onerous restrictions that it imposes on apps’ functionality.

For us developers, APIs are our windows into the platforms we work on. We depend on those APIs being documented, stable, and consistently available. On those first two counts, Apple has done a tremendous job in recent years. However, with the introduction of Mountain Lion, Apple has restricted a number of its newer and more interesting APIs to applications that are sold on the Mac App Store; if you are interested in what APIs are restricted, there are a number of them, but on the whole, they tend to be the ones that have to do with iCloud or the Notification Center. This is something of a Catch 22 for developers, since users are going to increasingly expect apps to provide the functionality provided by these APIs but may not necessarily want to purchase their apps via the Mac App Store. Once again, we have a case of Apple’s policies forcing developers to run afoul of users’ expectations.

What does this all boil down to? Apple’s recent policies make OS X development a lot more complicated for developers who want to keep up with the operating systems newest APIs but also are unable to comply with the restrictions associated with sandboxing. My take is that if you are developing a powerful application for OS X, odds are that you are going to have sell outside of the Mac App Store, due to sandboxing,  and live in fear of Apple one day using GateKeeper to further restrict the distribution of non-App Store apps. For another take on this, have a look at popular iOS developer Marco Arment’s post on the issue.

I know I have made some pretty strong statements here but I stand by them. If you would like to debate me on these issues or have any other feedback, find me on Google+.

WWDC 2012 Keynote Let Down

Earlier today I hosted Coder Radio with Chris Fisher of Jupiter Broadcasting and in the episode we discussed my reactions as a developer to the WWDC keynote this year (2012). First things first. I did not attend WWDC nor have I installed the iOS 6.0 developer release, so some of my information may be incomplete; I have to do this in this way due to Apple’s developer NDA. You can listen to the show to hear what I didn’t like, but I’d rather go through a few things that I would like to have seen that to my knowledge aren’t coming.

Inter-app Communications
This is by far my largest pet peeve with iOS development and using iOS. Why isn’t there are robust way for apps to work together and share data; within reason of course. Android has a version this in the form of “intents” and Windows Phone 7 has a incredibly powerful system called “contracts”. This really gets to me when I consider that iOS is a BSD system yet does not adhere to the UNIX philosophy of allowing many small applications to work together to do big things; yes, I know that iOS apps tend to be smaller in scope than their desktop counterparts but to date there is no real way for them to work together. There is so much functionality that cannot easily be done on iOS due to this restriction.

On my Android and Windows phone I can glance at the screen and get the latest tweets, view other data (such as a stock ticker), and play a song, or begin or pause listening to an audiobook. On iOS, almost all of those things require me to launch separate apps. That’s silly not to mention a bad user experience. I know there are definitely battery life concerns if you have too many widgets open, but there is no reason that Apple can’t add some sort of restricted mode for simple widgets to run in.

Siri integration
Ever since I got my hands on my 4S I have been waiting for a full Siri API. Apple has been working on it, but to date there is no fully functional Siri API for third party developers. This is understandable given how often Siri simply does not work but it is still a shame.

That’s all for now. Now I can finally take a look at the dev preview! For feedback please find me on Google+ or Twitter.

Review: Revolution in the Valley

Revolution in the Valley is the story of that first Apple development team that brought the world the Macintosh and in doing so changed computing history by making the computer a personal item focused on communication rather than computation.

Popular mythology portrays the development of the original Macintosh as a somewhat religious experience. In fact, that was not really the case. As with any large scale project there are problem, conflicts, and unforeseen bugs that raise both costs and tempers. Revolution in the Valley gives the reader what a more accurate account of the not only the development culture at Apple during its early days but also how large scale projects work in the really world when real people who don’t necessarily agree on the best ways to implement feature X.

As this is not a technical training or reference, there are really no prerequisites to reading but that does not mean that more experienced developers or even designers won’t get a lot out of the book; in fact, I always find it interesting to see how those early developers of the personal computer 1980’s  solved  complex technical issues with such limited hardware and software resources; after all there was no Github or BitBucket when the Macintosh was being developed.

In short, I would recommend this to anyone who works on or will be working on larger scale software projects.

For all the Apple haters, I know that my posts have been pretty Apple-centric for the last month or so, but I do have some interesting Android and other posts plans.