Archive for Apps

Hybrid Today, Progressive Web App Tomorrow

App (and I am using that term very loosely here) development has undergone a change. Most companies are eschewing high cost native development and for iOS and Android and going with hybrid solutions using tools like Xamarin or Ionic. This is a great way for organizations to lower their initial development and ongoing maintenance costs as well as get a useful app for their business needs. One area that many organizations are finding is that they still need desktop web applications and you don’t get the code sharing advantages between mobile and desktop platforms that you do between the two dominant mobile platforms – iOS and Android. Luckily, the march of development tools and frameworks has carried on and there’s a new solution – progressive web apps. These are web applications that live on the server but thanks to powerful JavaScript (or in some cases Typescript) can access native-like device capabilities. This, coupled with responsive development techniques and some adaptive CSS allows the app to scale in not only screen-size but also capabilities depending on the device. There are a number of frameworks that provide this, but my two favorites are Angular 4 and Polymer 2.

The Angular team now uses the tagline “one framework, mobile and desktop” and they mean it. Angular has come a long way from the original release of AngularJS and is now a full application development framework.  Currently, Angular is on version four and if you’ve used an older version of the framework you’re going to find major differences (especially in the area of routing) but the time invested into catching up is well worth it. Using Angular 4 you can now create a high-functioning application that runs on everything from your twenty-seven inch desktop screen all the way down to a mobile phone. I do find that there’s a bit more ceremony in the latest versions of Angular than in the first, but you could argue that’s an advantage, since it also makes the framework more flexible than its predecessor.

Polymer 2 is more focused on JavaScript components than Angular but is no less powerful. While the details of it works under the hood are different the end result is exactly the same — you end up with a powerful application that can scale for different screen sizes and devices.  If I had to make a comparison between Angular and Polymer 2, it would be that the Polymer team has made more of an effort to be “pure JavaScript.” I don’t love that criticism of Polymer for two reasons: 1) Angular is now written in Typescript and I (in my opinion) best consumed using Typescript and 2) some of the custom directives in Angular actually lead to less boilerplate than the more “pure JavaScript” alternatives in Polymer (especially around defining custom components), so I’d actually consider that a feature for Angular rather than a bug. Still, that doesn’t mean that Polymer is not a great choice for your progressive web app development needs.

There are of course other choices for developing progressive web apps but these two projects have the backing of Google and large communities around them, so they’re likely going to stand the test of time unlike the many <insert_noun.js>  JavaScript frameworks of the previous ten years.  The future looks bright for the progressive web app and by extension Angular and Polymer, given that the trend of businesses demanding more for less out of their developers and development partners is likely to continue.

If you liked this post, follow me on Twitter for more!

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

A Farewell to ‘App Developers’

I have had the great privilege of really coming to age at just the right time to be able to get into the ground floor of the mobile app development wave starting in 2008. In fact, to my knowledge, I opened one of the first three purely mobile app development firms in my home state of NJ.  While there were certainly ups and downs, I had a blast. Now it’s 2017 and frankly the party has been over for some time; in fact, I’d argue that for many in my position the end of 2014 and a good portion of 2015 served as a well deserved hang over. Before I get into what I really mean here, it’s important that you understand what things were like from 2008 to roughly 2013. Simply put, the market wanted “app developers” and there just weren’t that many, so an outsourcing / contracting boom began — entrepreneurs and enterprises both were handing out five and six figure checks to dumb kids like me with little to no vetting purely out of the ever present fear of missing out. It was an amazing time. Then the inevitable hangover hit. It happened differently for both groups but it happened and at the end of the day a lot of good small app development shops paid the ultimate price.

Every story needs a good fool and most of the app entrepreneurs (“apprenuers if you’re a hipster from Australia) fit the bill perfectly. Like the little girl who’s enchanted with the tale of the frog prince, they went out an got-a-kissin, cracking open their kids’ college funds or their 401Ks to be the next Uber or whatever the hot app of the week was at the time. Basically, they bought the Disney-like fairy tale sold to them by films like the Social Network. Unfortunately, like most fairy tales that Disney spins into feature films, the true source material ends in tears. Their assets drained, the vast majority of these would be Zucks left the app world with red eyes and broken hearts.

The enterprise space is a little more complicated but shares the fundamental error of understanding that the entrepreneurial one does – that mobile apps are one time capital expenditures rather than ongoing commitments. A lot of enterprises made exactly the same mistakes that entrepreneurs did, but their superior capital and (in many cases) diffusion of blame among managerial groups allowed them to simply swallow the pain and move on. Still, most IT managers now consider apps to be like any other piece of software they buy and not just some quick one off that they’ll let the local shop “take a shot at”. Sadly, this shift has greatly disadvantaged small vendors, as IT managers increasingly look to their traditional long-term software vendors for app development services as simple add-ons to their existing contracts. It’s easy to take a Darwinian perspective here but the truth is a little more dirty than simple survival of the fittest in terms of big vendors and small vendors. Large vendors made it a habit (and still do) of externalizing their app development services to smaller more focused shops. I can tell you that this was fine for a time, but then something changed.

The large vendors realized that it was cheaper to just internalize or in some cases contract out to individual 1099s for their app development services and simply cut the little guys out. We’re in 2012 here now and I surmise that beginning of the app market cooling and an increased pool of young app developers out their had a hand in this. Some went as far as using legally restrictive language in their contracts with the smaller firms to prevent them from using the subcontracted work they had done in their own sales efforts. Imagine being one of these small shops for a moment. You wake up one day and in your email is a termination from one of your biggest “partners”, then the same thing the following week, then again the next week. In a month, you’re waking up to having nothing in your portfolio and payroll outstripping revenue on a monthly basis. What do you do? Do you take the risk and breach your contract, risking a C&D or possibly a full scale lawsuit, do you try to dance around it by mentioning the projects verbally but keeping them out of writing? What happens if you finally have a sale about to close but the prospect wants you to “prove it”? Your former client who overnight became the Empire to your rag tag Rebellion sure as shit isn’t going to give you a reference and might even poach the deal if you try to use them. Welcome to 2015.

I’d like to say that this story has a happy ending but in reality it doesn’t. Many shops closed their doors in 2015 or were forced to restructure in some significant way. Put simply a lot of good people lost their jobs, a lot of would be entrepreneurs felt cheated, and the owners / shareholders of the large IT firms made just a little more money. Even among the survivors “app development” as it was in 2008-2012 is over and they are struggling trying to become small enterprise IT vendors but growth is nothing like it was during the nascent period of app development. Let’s all remember those halcyon days as we look at our CRMs and wonder what the Hell happened.

Like what you read? Don’t forget to subscribe and follow me on Twitter.

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.

Linux Adventure Pt 2: Ubuntu Apps

UbuntuMy Linux adventure continues on my modest Dell workstation. I’m pleased to say that so far things are going very well and Ubuntu continues to bring new life to my otherwise underpowered workstation. After getting over a few hurdles, what’s really impressive about my experience working on Ubuntu daily is how uneventful it is. Still, there’s always some room for improvement and the most glaring pain point is the lack of decent apps available for the operating system. Ubuntu just doesn’t have a good app ecosystem compared to MacOS and the Software Center is little more than an embarrassment.

Developer Interest: The simple and most basic cause of this is that there just aren’t many apps available, since developers don’t see Ubuntu as a platform worth developing for. Unfortunately, that’s probably true to a point. A simple Google search for developers considering moving their app project over from MacOS or Windows to Ubuntu, doesn’t yielding very heartening results. There also is something of (what I believe to be a misconception) among some developers where they believe that Ubuntu users are unlikely to purchase software.

App Distribution: Canonical, the developer of Ubuntu, released the Software Center several years ago with the hopes that it would become the equivalent of the App Store on MacOS. Unfortunately, the Software Center was poorly implemented and little to no effort was made to draw developers to the platform. Failing the Software Center, developers are left to their own devices for delivering their apps and there’s little standardization on Ubuntu or Linux as a whole for that matter when it comes to the easy distribution and installation of GUI apps.

The advantage of Ubuntu and Linux operating systems in general is that there are steps that the community can take to resolve issues on the platform. For instance, the community could develop an open-source alternative to the Software Center and encourage its adoption. Of course, Canonical could accelerate the process by throwing their development and financial weight behind such an effort and making a clearer statement about where the platform is headed.

Let me know what you think? Do you see Ubuntu as a viable development platform? Reach out to me in the comments below or on Twitter.

 

UPDATE: I have been made aware that the Software Center launched before the Mac App Store. I appreciate the correction. This only makes Canonical’s failure deeper, since they’ve had more time to work this out. Maybe the GNOME store will be better but I don’t think being first is in any way valuable in terms of being a developer and considering developing commercial software on the platform.  

Xamarin + Microsoft

MicrosoftXamarin2

Today it was announced that Microsoft is acquiring Xamarin. I’m well on the record as having some mixed feelings about the Xamarin platform. Details are still pretty few and far between about the structure of the deal (other than the obvious fact that it’s a straight acquisition) or what Microsoft intends to do with the platform once they have control of it. Hopefully, Microsoft can leverage its resources to resolve improve Xamarin’s core weaknesses: pricing and Xamarin Forms.

Far be it for me who has railed that we don’t charge enough for software in general to criticize a company’s pricing structure but Xamarin’s pricing really leaves a bit to be desired. My issue is not with the dollar price per se but with the fact that you can’t code in Visual Studio, a far superior experience to Xamarin Studio, with the Indie license and that fact that LINQ to SQL is only available at the Business tier. It would be much more appropriate for the tiers to be separated only by support and SLA’s rather than actual functionality provided in the tooling.

Xamarin Forms, though it has gotten better since I last looked at it, needs some attention. The truth is that most internal development projects don’t have a focus on the platform specific user experience and managers would love to deploy a write once run everywhere solution.

It’ll be interesting to see how Microsoft takes Xamarin and supports its developers and if you’re interested in getting a mobile development project done, please fill out the form on this page.

A Farewell to Apps?

Ars Technica recently posted an article by Larry Seltzer that discusses the possibility of native mobile apps being marginalized by web-based solutions thanks to the increasing advancement of web standards on mobile. Normally, I’d ignore something like this — in most cases when you see the tech press post a headline that’s something akin to for will A kill B, you can rest assured that the content will be fairly overstated and that you’ve been taken by a click-bait title. For the most part, Seltzer does a good job of understanding some of the challenges faced when using web-based technologies to develop but overstates the desirability of having mobile websites replace apps while simultaneously overlooking obvious shortfall of a pure mobile-web only strategy: performance.

JavaScript interpreters have been getting better and better every year and most JITs (just in time compilers) are on track to annually provide “free” performance increases on most browsers for most common use cases. However, they’re not keeping up in terms of raw speed with optimized native code on specialized hardware — for instance, Swift code on Apple’s A8 processor in the iPhone 6S. Another thing to consider is that all of the code on a mobile website must be run through the browser’s JavaScript interpreter.

The idea that native apps aren’t necessarily right for all business needs is pretty obvious and I agree with the author up to that point, but most of the technical issues that he mentions have been addressed by hybrid apps. Hybrid apps using Cordova-based tool-kits such as Ionic address the most common performance issues seen with mobile sites and the lack of web-based APIs for some many hardware features by actually having native level tie-ins. Basically, they implement native API’s a layer below where the developer writes his app logic and expose a JavaScript version of the APIs for the developer to use. From a technical perspective, developers can write any hybrid plugin for any functionality released in a future version of Android or iOS, then access that functionality via JavaScript.

Mobile websites do have one advantage of packaged apps and that’s that they do not have to be distributed via the AppStore. This, however, is not a technical problem, but rather a policy one. Apple still opts to manually approve every single app submission and app update for their iOS store and that creates an artificial delay between developers completing a release and users being able to install it; in cases where the developer is fixing a major security issue, this can be devastating and needlessly exposes users to risk. Still, the advantages of being able to tie directly into device functionality and the performance increases gained make publishing apps via the AppStore mechanism or some enterprise deployment scheme the right choice for the vast majority of apps whether you are developing using native or HTML5 technologies.

Going Mobile: Oyster

Reading is one of the few constant pleasures I’ve had my entire life. As a young boy, I used to accompany my mother to the local Barnes and Nobel once a week, not to purchase but to read books — my mother was kind enough to purchase me a book once every other month or so, but that’s a story for another day.

Overtime, my reading habit started to get a little too costly and I quickly had to turn to some desperate sources, such as the Dunellen Public School library who, despite doing the best they could, had little more than a shallow offering on a relatively narrow range of subjects.

One day everything changed. One day Amazon released the Kindle. The Kindle was a revolution for me and significantly lowered the cost of my drug of choice. Unfortunately, it turned out to the heroin to my cocaine and my habit became an increasingly frequent one.

Oyster aims to act as a methadone of sorts for my reading habit. Basically, Oyster is a subscription service for ebooks. It works in a very similar way that Netflix or Spotify do but you can tell based on the selection that this is an area that the publishing industry is not exactly jumping into lightly; indeed, it can be a challenge for me to find titles that are of interest to me and that I haven’t read. Still, for the price (just under $10 per month), you can’t go wrong if you can manage to read at least two books per month.

Happy reading! Please follow me Twitter and remember that this post is brought to you by Fingertip Tech, INC (@FingertipTech) who would love to help you with your app project!

Going Mobile: Overcast

icon_340This is the second entry into Going Mobile, my series of reviews on mobile software. Frequent readers of this blog will notice that this series used to only focus on productivity software but is now expanding to the wider app ecosystem. I’m still taking a special focus on apps that actually allow you to “get things done” or provide a certain level of productive value.

This week I’m really excited to be taking a quick look at a brand new app by the nerd-famous Marco ArmentOvercast. Overcast is basically a high-end iOS only podcast client. As a podcaster myself, please check out Coder Radio if you are into development, I get really excited when a top-tier developer like Arment puts something out in the space.

The Good: Overcast is fast. I mean lightening fast. I’ve been using it since day one and have yet to find any noticeable lag or stuttering with any of the animations in the app. To be fair, some of this is due to the app’s arguably spartan design; in fact, other than the app’s logo, it uses all standard iOS controls, something that works surprisingly well and is refreshing when compared to some of the overly “designed” apps we’ve seen over the past few years.

Though I am not a huge fan of playing podcasts at higher than 1X speed, it’s good that Overcast offers the ability to finely control how fast you are playing back the audio. Like all of the app’s features, this is elegantly tucked away and is in now way intrusive.

The Bad: Overcast is free to download and use to a point and Arment has been pretty generous in what features he allows you to access before paying the $4.99 upgrade price; in fact, you can use some of the premium features for free with limits without paying – it is a little shocking that Apple allowed this, given their relatively hard position on trials of any kind. However, Arment’s generosity doesn’t make up for the fact that “smart speed”, the apps signature feature, is just not very impressive and I’ve found to not work pretty very well for the majority of podcasts in my somewhat extensive library.

The Ugly: It is a little disheartening that someone like Arment who has a following and could release even the simplest of apps and still get some immediate and great press felt that even he had to go with a freemium model to make a decent profit on the app. Arment’s done freemium in the “cleanest” way I’ve seen so yet but it still feels a bit unfortunate that it had to be done.

Conclusion: If you subscribe to more than three podcasts and use an iPhone, then you should give Overcast a shot.

Slacking Off

Slack

At Fingertip Tech, INC HQ collaboration is key, so we’ve been searching for tools to help us better work together as a team. We’ve worked with a few tools over the years but none has fit our work model as well as Slack.

Slack is very similar to HipChat, the tool it is replacing at the Fingertip HQ. The main advantage that makes Slack the winner for me is its better user experience and greater focus on design than HipChat and pretty much the rest of its competition.

We’ve found it easy to integrate Slack with all of our most important services – especially our self-hosted (on Digital Ocean) GitLab source control system.

Of course with any tool, there are downsides. For instance Slack doesn’t have an app on any desktop platform other than Mac OS X. Additionally, Slack’s Mac app does not feel very native; in fact it seems to be a wrapped HTML5 app – this is something that rubs me the wrong way but in practical terms rarely becomes an issue.

Being grounded in web technologies does make its Chrome app one of the most impressive Chrome apps I’ve used in some time.