Category: Hybrid Web Apps

What companies want from an Ionic developer

I’ve recently started a new Ionic project, where we are already using Ionic v4. Through chatting with the team, I’ve realised that being an Ionic developer is a specialist role and by working as a developer in such a specialist role there is more to it than being able to code.

When a company decides that they are going to be developing their new mobile project in Ionic, they are making an investment in a technology that is not yet the norm for building mobile apps. They have spent the time to look into alternative ways for creating their app, they need to be sure that the road they are going down will mean that the app being built can fulfil all the business needs that they have for the app.

With native app development, the path has been proven. There are tons of examples of business apps developed in Swift or Java that show whatever the company’s needs are a native app can be built to meet those needs. But as we know as a hybrid developer, there are a few drawbacks from building native apps. There is cost, there is timescales and availability of development skills. All things to think about when deciding what to use to get their app built.

So when a business has decided that they want their app built using Ionic as the ‘Ionic developer’ who is working on the project you are seen as the expert. Not only should you be able to develop an app with Ionic, but you need to be able to guide the business through the process of having building a hybrid app.

The sort of advice you will need to help the business with could include, how will the app perform in relation to other apps they may have seen? You may have to convince the business that the app is fast, or appears fast to the user. How will you add features that show the app is fast? You’ll have to suggest ways like having loaders when data is being retrieved, showing update messages when a form is being submitted. Do you know how to partially load data into the view, so the user sees something as soon as data has been received.
You have to also show them how an Ionic app will be deployed. What are the various options? Are they going through the App Store or are they looking to use the Ionic Pro tools, do you know what the Pro Tools do? If they are using them you’ll have to help with the deployment stage.

Security is an important part of any business app, so you’ll have to know about the different approaches there are to securing an Ionic app. You’ll have to be able to advise on what Cordova plugins could be used to store data securely. You may also need to what other options they could use to secure an app. Is biometrics an option, could they use the native finger print reader within the app? How would you suggest API tokens are stored and passed with every API call?

If the business has an existing design style, how will that work within a mobile app? Does it work across all platforms and still look and feel as a native app should for the user? You will have to give the business advice on how the app will look in order to work for the user, without trying to tell a professional designer, who knows more than you do, how to design.

There are a lot of questions that a business will have when going through the process of having an Ionic app developed. As the Ionic developer you need to be able to guide the business through this process. It’s not just a case of just sitting behind a monitor with you headphones on writing Ionic code, you need to actively work with the business in all aspects of building the app.

But there is more we can do as Ionic developers. We can write blog posts on how we solved these types of questions. There are many brilliant blog posts on how to create an app with Ionic, but there aren’t many about how an Ionic developer has used the framework and the tools Ionic provides to solve a business need.

I’d like to see more blog posts on how security was built into an app, how data is stored securely in the app. What methods someone used to shows that the app is performing really fast, how was this monitored? What ways was the UI setup to show to the user the app was performing well for them?

There are many examples of posts about the setting up and building of an app and this will continue now we have Ionic 4 coming out with its support for multiple frameworks. I’m in the process of writing a book about Angular and Ionic, where I go through the basics of creating an Ionic app. This is all great for new developers coming to Ionic, the more we have the better.
But I think we also now need to show how we as Ionic developers are using what the framework provides to show businesses and enterprise level companies how Ionic can be a viable option for their next business application.

As Ionic developers we need to be this guide for businesses as well as developers. With Ionic 4 coming soon its time we stop telling each other how great Ionic is and now start telling businesses how great an option Ionic is for their next app.

Writing good Pull Request descriptions

As developers, we like to get work done quickly. There is a feeling that if we finish fixing an issue or completing an issue as quickly as we can, then is obvious to the other team members, who may not be developers, that we are good at what we do because we get things done quickly.
This is dangerous, it can lead to bad practices slipping into your teams’ processes, where developers are trying to cut corners and get that Pull Request (where a developer asks the rest of the team to ‘pull’ their code into the main codebase of an app) ready as soon as possible.
One area where this cutting corners can happen is in PR (Pull Request) description messages, where the developer explains what this PR is about. If this is not completed then all the other member of the team who is reviewing the PR (where a second developer looks at the code changes made, and checks for any problems or can suggest ways that something might be done in a more efficient way), this second developer will just be shown a list of files, with the code changes highlighted.
From that, they need to work out what this PR is trying to either fix or add to the app’s codebase. Usually, without this context, the second developer will look at the changes, and think ‘well the syntax of the code looks fine, there are no obvious problems with how it’s written, I’ll Approve it’. Then this new PR is added to your app’s codebase, it all works and everything is fine.
But a few weeks later your users are complaining that the app has a strange issue when they use it. So you ask your developers to look into the cause of the problem. It could be due to something that has gone in the latest version of the app. So as any good developer should, they look through all the PR’s that went into that last release of the app.
This is where having a good description of what was done for a PR is so important. Yes, you can find a branch number that matches the list of the branches of code that went into a release, but if there is no description or no context of what work was completed as part of the PR, then it all becomes a guessing game.

So what goes into a good description?

There are a couple of things I think should go in a PR description:
1. Ticket number and title
2. A brief explanation of work completed
3. Bullet list of changes made

Adding a Ticket Number and Title

The title of a PR can have a lot of different variations, I’ve seen some places where the title is used to show a log of the changes made. From the PR’s in a release a log showing all the titles was used to show a report of what went into a release. This is helpful, but it meant that all the PR titles needed to be in a certain format and this format wasn’t particularly reading for humans.
Having the title of the ticket and the title number in the description as the first line makes it possible for a developer to see what was the corresponding ticket (if we’re using Jira) and what the name of the ticket was. Then the developer can search for that ticket and get an overview of what the PR was trying to do.

A brief explanation of work carried out

Next, I would add a brief, a few paragraphs, not an essay, an explanation of what work was carried out, what was added or fixed and how this was done. So someone could read this and get a sense of what was completed in the PR.
This doesn’t have to be too much, just enough so anyone knows what work was carried out.
A description is not only useful to other developers who may have to work on an old PR but also the original developer, to remind them of what they did for the PR.

Bullet list of changes

This is where you just list the changes you made. Maybe list each amended or new file and list what changes were made. Something like:

  1. Add new sort function to account service
  2. Removed commented out code from the interface
  3. Add unit test for main login service

Along with the title, brief description and bullet list of changes it is clear what went into a PR. Making it easier for developers in a team to be able to see what went into a PR.

Some developers in your team might say that this is a was of time, and if you need an explanation of what some code does then it’s not well-written code, but I think that’s laziness on the developers’ side. No one’s code is that easy to read, especially after a few months. Having your developers follow the good practice of adding a description to any PR they make will no doubt help the team. The more the team know what’s been added to the code base the quicker a fix for an issue with an app can be fixed, the faster the fixed app can be released to your users.

If your team aren’t using descriptions in their Pull Request’s then maybe its time to ask them why, and if they say it takes to long then make sure this effort is included in the estimates they give. It’s work the time in the long run.

The rise of hybrid and a question by a Mac developer

Recently the great Mac app developer Brent Simmons posted on Twitter “Sometimes it looks like there are people *rooting* for the demise of native Mac apps. Why?”   This started a long thread from various other Mac/iOS developers, all giving their opinion on why this is. Some said it was because of the UIKit which is used to layout Mac apps and how slow it is compared to using web technology others said it was a skills issue. Easier to find JS/Web developers than Mac developers.

What stood out to me about this question, is not the answers, I really don’t know if the APIs used in Mac development is slower than web development or not, what I found interesting is that one of the leading Mac developers was asking why more people are interested in using web technology than native to build Mac/iOS apps.

This is the first time I’ve seen from the other side (hybrid vs native) it’s interesting to see that now native developers are seeing this rise in hybrid apps, or apps built using web technology as a concern. It shows that the growth of developing apps using HTML/CSS/JS is getting more prevalent and Mac app developers are starting to notice this new trend growing.

Does this mean that hybrid app development has won this ‘war’ on native vs hybrid, well no, because there probably isn’t a war between the two sides? It just means now there is another viable option to native development, which a lot of developers are now taking advantage of. Whether it’s because of the latest performance gains in web technology is making building apps with web tech a good option or there are more web developers moving over into app development as well as web development, who knows. One this is that now apps can be developed either the native way or the web way is a good thing. It’ll lead to more opportunities for developers, and better apps for users.

Does it matter what an app is built in?

Well not really?
There has been a big argument on Twitter about NativeScript vs Ionic or NativeScript vs Hybrid and how you can upgrade to NativeScript from hybrid.
Of course the hybrid people weren’t to keen on that idea.
But really in the end it’s all about the app and what it can do and how it performs. I choose to create Ionic apps because I like how Ionic works, and how you go about developing Ionic apps.  I think the team at Ionic have done a fantastic job creating a framework and SDK that allows me to create cross platform apps.
It only matters how apps are being built if you have something to sell about how apps should be built, whether it’s a book or a course. Me, I like to build apps that perform well, look good and do exactly what the clients what the app to do.

The Rockd app really does rock

I recently read a great post on the Ionic’s Medium blog highlighting a new Ionic app called Rockd. I’m not a geologist, but this app looks really good.

What I like most about it is that is shows that mobile apps can be more than just games or productivity apps (which I do like). Mobile apps can be used to support a hobby or learn about a new skill. As we move into a more remote work place, mobile apps can help organisations and their employees work better.

I think that Rockd allows users to discover more about geology, it’s good to see an app developed for something else.

Ionic 2 links

I’m starting to look into learning Ionic2 (and Angular2) so here are some links to articles and resources I’ve been reading about Ionic 2:

Here are some great videos:

These are just a few of links I’ll add to them as I find more. I’d also recommend the Building Mobile Apps With Ionic 2 book from Josh Morony

Can you call yourself an Indie Dev

As I’ve mentioned before I’m a big fan of indie devs. And one day hope to be in a position where I can make a living being an independent developer. One question that does cross my mind is can you call yourself an indie mobile developer when you don’t write native apps?

The obvious answer is yes, it really doesn’t matter if the apps you build are built using Objective-C, Java or JavaScript. As long as they sell and are good quality apps then it doesn’t matter.

But all the indie devs I know of seem to just build native iOS app. This is probably because the iOS market and app store were the first so developers went and joined the iOS market building native apps. There is a Slack channel for iOS developers, which I belong to. In this channel there are a lot of developers who are building apps for themselves either full time or part time. But all of them seem to be native developers.

I think that being a hybrid app developer would be a good thing for indie developers. When they create an app they can target both major platforms (and now Windows with Ionic 2).

I suppose the question is not what programming language you use to make apps but more how successful you are at shipping apps, marketing them and expanding upon them. I’ve posted a question of the Ionic slack channel to see if any developers there are independent it’ll be interesting to see the response.

Why I like using web technologies for mobile

I was walking my dog this morning, thinking why do dogs like sniffing where other dogs have peed (pretty gross) and if I was asked why I like using mobile technologies for building mobile apps, what would my answer be.

Well there are a couple of answers to that question. First I think that if you are running a web agency and one of your major clients comes to you and says ‘we love the website you created for us, can you also build us a mobile app that uses a feature of the site, and we want it in the next 6 weeks’. This a great example of when a hybrid or mobile technology built app (NativeScript or AppCelerator) is a great solution. Because it allows the web agency to use their in house skills straight away on the project. They don’t have to hire either an iOS or Android developer, they can get the web developers they have starting on the project.

Another time a hybrid app is a good solution is when someone has an idea for an app, but don’t have the skills required for building the app. They do know that they want to hit both iOS and Android (and now Windows with the latest beta of Ionic 2). Getting a developer who can build a hybrid app will allow the app entrepreneur to get a version of their app out there to customers to see how well the app does and if their idea takes off.

I do think that hybrid is not the answer to everything. Apps that need to be high performing, or need to closely integrate with OS native is the way to go. Also if your company is large enough to have it’s own in house native developers then it make sense to use what skills you already have.

On the flip side of this argument is this article by Keith Elliot – Your Hybrid App is Going to Kill You (a bit harsh title, but still an interesting read).

My thoughts on the mobile web 

Currently the mobile web is growing and growing, every week there is a new ways of using web technologies to create mobile apps.My weapon of choice is Ionic, mainly because the Ionic team have created a framework that allows a web developer to create apps that work well and look fantastic. 
It really shows the power of the web, it’s everywhere, you can build anything with just HTML, CSS and JavaScript. For a company who want their product to reach as many platforms as possible, the mobile web is the ideal solution. A single web developer can built apps for mobile, tablet, desktop and now TV.

The web has always been an exciting place to be, but now with the options for the mobile web, being a web developer is a great place to be.

Unfortunately with more and more technologies coming out, different approaches to using web technology to develop cross platform apps. This ‘my technology is better than yours’ arguments start. Usually these are fuelled by the companies who’s technology it is. I mean they have to sell their product. But what is better, native, hybrid, or these ones that use web technologies to compile down to native. They are all great, but for me as a web developer I want to be able to create great apps for as many platforms as I can. For the people who use these apps, they don’t care what technology the apps was developed in. All they care is it works as they wanted to, it’s fast and looks good. For me as a web developer I want to use something that I can use my current skills for and Ionic is my platform of choice for these reasons.

So web developers enjoy this current growth we have in the mobile web it’s a very exciting time.

SyncHerts mobile development event

I went to my first SyncHerts event in a while. It was about mobile development, a favourite subject of mine, so I was keen to see what others in the local area are doing.

This was the second part of a 2 part event. In the first event people broke into teams and wrote user stories and made UI designs. In this the second part they needed developers to actually make these apps.

so again we split into teams and as the developer in the team I started making the app with Ionic. We only had 20-30 minutes before we had to demo to the other groups, which isn’t long enough to create a fully featured apps. But with the power of Ionic I was able to build an app that loads in a JSON file with a list of pizzas (it’s a pizza ordering app) then when you select on a pizza you get to see the full details of the pizza. Finally we added a Order button, so people could chose which one they wanted ordered for the next meet up.

We weren’t the only team using Ionic, another team had created a Ionic app that used a carousel to go from one pizza type to the next. Another team used Xamarin, and another team used Bootstrap with ASP MVC.

It was interesting to see how quickly people could get something together in such a small space of time. It was also interesting to see what technologies people would use.

I was impressed with how quickly you could build something that looked OK and worked using mobile web technologies like Ionic.  I was also able to load the app on my phone to demo using Ionic View.

I might add to the app and get it on GitHub