Tag Archive for Mac

Why I’m Selling My MacBook Pro – Focus

In a word – “focus.” There are a lot of cool technologies available to developers to today and the truth is that, I’ve been spending a lot of time chasing a lot of different albeit very interesting technologies and trying to figure out what makes sense for myself and for Buccaneer. Here’s just a brief list of the things that I’ve found incredibly interesting technology-wise over the last eighteen months:  Docker, Swift, Linux, iOS development, Android development, Arduino, 3D Printing, DevOps, Angular, React, and about a thousand other things. All of them are very cool, but there’s not a lot of depth one developer can get in any given technology if he or she is focusing on more than one or two of them at a time.

So what does this have to do with selling a Mac. Well, I spent years writing iOS apps in Objective-C and a significantly smaller amount of time writing them in Swift and that was fun for a long time, but now Buccaneer and I have moved on to the exciting world of Containerization via Docker and the wider DevOps space.

For a time, I was trying to juggle these two priorities but what I found was that if you have two messages, then all you’re really messaging is a cacophony of white noise. Another aspect of this is looking into the future based on the current tech trends. While there still are some advantages to native apps over hybrid apps, most enterprise customers are correctly focusing on hybrid or web-powered apps or those who have a little more tolerance for a performance hit are skating to where the puck is likely going in the form of progress web apps. Enterprises are really deciding between hybrid apps with tools like React or Ionic or full on progressive web apps using something like Angular or Google’s Polymer. The reasons for this tend to be the usual development and maintenance costs arguments but also that most of the complexity in enterprise systems tends to be on the back-end rather than the client-side.

My solution is extremely simple — to just skate to where the puck is going and that’s toward thinner clients with complicated back-end systems. These back-ends will be hard to maintain and that’s where containerization provides value and I find that sort of work is best done on a Linux workstation, so I’m going Linux 100%.

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.

MacBook Pro 2016 Review

I’ve been having a lot of fun working on Linux over the last few months and continue to use it as one of my two daily drivers, but the realities of corporate VPN policies and the fact that even Ubuntu is not supported by most common corporate VPN clients forced me to pick up a Mac. Being the type of guy that likes to go big or not at all, I went for the 15” MacBook Pro. Take a look:

Sure it’s not the absolute highest end Mac you can buy but it’s by no means a slouch. Here’s some thoughts after working with it for about two weeks.

The Good: The MacBook Pro has the best screen I’ve ever seen in any laptop in over a decade of being primarily a laptop user. The build quality is very good and the “Space Gray” gives it that “pro” feel I’ve found missing in Apple products for some time. While I’ve been pretty critical of the full-fledged (one might even say “courages” adoption of USB-C over USB3), I see the long-term value in having all your devices use a standard port for charging and data transfer, however, I question if Apple would be willing to have the iPhone adopt the standard as well in it’s next iteration.

The Bad: While the MacBook Pro feels premium in practice its performance doesn’t feel like the nearly $3,000 I paid for it. Knowing that it doesn’t run Kaby Lake may be part of my problem and certainly for that amount of money, I’d like to at least have the option of more than 16GB of RAM. Also, the price jump between storage configurations feels a lot like gouging. All in all, the worst part of this machine is the price tag and feeling that you have “SUCKER” painted on your forehead when you compare the price to the specs.

The Ugly: I’ve developed Mac apps and iOS apps for a long time and in the past I’ve be skeptical of Apple’s additions to both platforms. In most cases, I’ve been forced to at least concede that some users may like some features. This simply is not the case for the TouchBar. Try as I might to find a productive and interesting use for it over it’s classic function row predecessor, I’m left feeling like I am holding what in ten years will be a curiosity of Apple hardware design history that is unlikely to be widely adopted by developers let alone repeated in other product lines. I also can’t help but feel that the TouchBar is at least partially responsible for the hefty price tag.

Overall, the MacBook Pro is a fine tool and it does a job that I need done. If you’re looking to fall in love with a device, you’re in the wrong place. However, if you are like me and consider your machines tools to do work on (much a like a carpenter might look at a particular table saw or hammer), then you’re likely going to get some return on your investment and be happy in the end.

Code Journal 1.3.4 Update

050413_1245_CodeJournal1.pngCode Journal 1.3.4 is now available on the Mac App Store for free. This update includes a number of small bug fixes. There are a lot of big changes coming to Code Journal over the next few months and I think it is really going to take the app in a great direction.

I’ve taken your feedback on the app and in particular feature requests and, though no new features are included in this update, new features and the restoration of the Gist functionality is on its way.

Stay tuned for more updates!

 

Thank You!

Code Journal LogoCode Journal has done extremely well on the Mac App Store recently. It reached as high as number 31 for free apps overall and number 2 in its category. Needless to say I was shocked by the sheer number of users downloading the app. For the most part users are happy and the app is working as expected. However, there have been a few issues that have cropped up over the last week.

Like many API providers Github limits third party developers to a certain number of API tokens and requests per time period. What this means in real-world terms is that if you are a third party developer, like I am, and you see rapid adoption of an app that hits their API, you may start to see some issues for some users. This issue has been further exacerbated by the fact that iPhone version of Code Journal currently uses the same tokens as the Mac version available from the Mac App Store and my site. Steps have been taken to resolve this issue on two fronts: one Code Journal for Mac now has more tokens and two once the next editions of the Mac app and iPhone app are approved, they will be using different tokens — essentially doubling the pool for both apps!

I’d like to personally thank all of you for giving my little app a shot and I would especially like to thank those of you who have emailed me your constructive feedback and were patient during the token drought. Your continued support has meant more to me than any chart ranking and I am happy to report that I will be releasing another free app on an Apple platform in the coming month or so. Stay tuned! And thanks again!

I welcome comments or replies to this thread on Twitter or Google+. If you haven’t already, download Code Journal from the Mac App Store.

The Best Feature…

Code Journal LogoI’ve been hard at work mapping out the future of Code Journal  and took some time to go through user e-mails that requested new features; the idea was that I would simply implement the feature that the most users had e-mailed asking for. That feature was a resizable UI.

The problem was that the people, my customers who I of course care a great deal about, were very passionate about this particular feature and the feature seemed simple enough to implement; after all, I’ve implemented resizable UI’s on a number of Mac OS X apps for clients, so why couldn’t I apply the same the techniques to Code Journal? Right? Wrong.

Code Journal started out pretty simple; it was an app that pulled and processed JSON data from the Github API; in fact, the most complicated thing in the private demo (think alpha) version of the app was Github’s OAuth. I was thrilled. The app was nice and simple.

Overtime and as it closer to the all important 1.0, compromises had to be made. There is no need to enumerate them here, but suffice it say that one current feature (Github Enterprise support) is responsible for a disproportionate amount of code and almost all of my support requests. Does that mean I’ll be pulling enterprise support? Absolutely not. The truth is that these request have more to do with customers having non-standard settings on their Github Enterprise deployment or the server that host them, rather than anything to do with Code Journal. Enterprise support is a slam dunk and I personally love being able to user Cde Journal with clients who have Github Enterprise servers; best part is that most of the time all I have to do is fill out the enterprise field in the app with my credentials and we are good to go — no need to bother a sys-admin at all.

In short, the complexity that supporting enterprise customers caused was a good thing. Back to the feature request: resizable interfaces.  I understand why some people might want this feature, but, to be honest, I don’t think it’s a good idea. Even on my 27 inch Cinema Display, I often find myself pressed for screen real estate when tacking some hairy memory management problem or am “in the zone.” Like many of you, I am not willing to compromise by putting my monitoring tools into a separate space and, again like most of you I imagine,  I only have the one screen. The other issue of course is that Code Journal is a Mac app and a lot developers that work on Macs work on 13” laptops.

Still, it’s hard to ignore your paying customers, so I went against my instincts and began coding.  I won’t bore you with the details, but it was doomed from the jump. I spent two weeks coding and agonizing over resizing table views and experimenting with Auto Layout. What resulted wasn’t terrible but had a number of rough edges and, more importantly, was not a feature that I could see myself using and believe would have been a major source of maintenance. The feature is not going to be released. At this point in the product’s life, it is more important to keep complexity out of the equation than to add every suggested feature; this particularly true of features that don’t provide any additional functionality. The best feature is the one you never have to maintain.

Comments? Questions? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me. Also, check out the new free version of Code Journal for iOS.

 

Pricing: We’re Doing It Wrong

Like many of you I am an independant software developer and have found some success leveraging the App Store. Many developers, myself included, have bought into the low price / high volume business model and we’ve had some mixed results…. I’ve been considering the pricing issue for a while and have come to an odd, but by no means original, conclusion: we are all underpricing ourselves. Please note before you read this that I am excluding games from the equation here

This might sound strange given the rise of freemium software and the general wisdom that cheaper software sells in higher volumes. However, it doesn’t seem to hold up.  Taking a fast look at the current top ten grossing paid applications on the Mac App Store, the average price of an app is $75 and the most commonly appearing figure is $20. Now before you get too excited about that $75 figure keep in mind that the average is shot up by a few apps at $200 or more. Also, keep in mind that I am using the ‘top grossing’ for my metrics rather than ‘top paid’; I’m using ‘top grossing’ because it isn’t clear what it means to be a ‘top paid’ app but an app’s gross revenue is an accepted metric I can use to judge its commercial success.  A few other things I’ve noticed from looking at the top grossers: none of them is $0.99, none of them is $1.99, none of them is even $4.99, and the lowest priced apps are $20.

To be honest, I don’t know what price points we should all be hitting, but anything below $4.99 for desktop software seems like far too low; in truth, I am starting to feel like the $4.99 price point is even a bit too low given how much work we put in our products. All I know is that we (software developers) need to end this race to the bottom on price.

Comments? Questions? Drop me a line on App.net, Google+, or Twitter. Also, pickup Code Journal.

Macbook Air for Development

If you have been following me on Google+, you may know that my beloved Macbook Pro had a little accident; I was working late and was extremely tired and I dropped my full mug of coffee directly onto my Macbook. That’s right the entire mug of steaming hot coffee went directly into my almost two thousand dollar laptop. Desperately, I began to dry off the machine and attempted to use compressed air to force out the moisture. I did this for some time  but finally had to go to sleep. All I could do was wait. In the morning it became clear that my machine was a doorstop, so I drove to the nearest Apple Store and made a purchase.

 

The laptop being replaced is a Macbook Pro 13” i7 with 8GB of RAM. By any measure it is a powerhouse for a laptop; full disclosure it has had some trouble with kernel panicking that I believe were due to overheating.

 

As usual the Apple Store was jam packed, so I had to wait to speak to an employee, but that was fine, since I had not yet decided what to buy. I knew I wanted an Air; my experience with my XPS 13 has sold me on the virtues of SSD’s and frankly traditional spinning drives feel a bit antiquated to me know.

 

I also looked at the retina model for a few minutes. I can’t deny that it looks very pretty, but the web is not retina yet and the cost is a bit more than I want to spend; I have been going through a Mac laptop about one every eighteen months, so spending over two thousand dollars on a machine seemed foolish to me. Another point regarding resolution is that the Macbook Airs are all higher resolution than the machine that I was replacing and they look stunning.

 

If you can’t figure it out already, I bought an Air. I had thought that I needed to have the same amount of RAM as my pro, but, having done some research and having worked on my XPS a bit, I came to the understanding that an SSD really makes the most difference for the type of work I do on my Macs: iOS and Mac development.

 

For the stat minded, I got the 13” Air with 4GB of RAM and the 128GB SSD hard drive. Or in other words the base 13” model. How’s it going? So far so good.

 

Comments questions? Find me on Google+ or Twitter.

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+.