Ionic Framework – Geolocation iOS Store issues



As I have recently published my Ionic app CoffeeTrail into the iOS store. I wanted to share with you some issues I experienced while trying to upload it.

Android Coffee Finder Application CoffeeTrail

In total, the app was rejected twice due to lingering issues with my Ionic Native Geolocation plugin. These two issues were easily fixed although initially it wasn’t very obvious.

The first, was the lack of specificity when asking for the users location . A modal pops up asking for permission but I didn’t explain why I wanted to use their location. This goes against the iOS human interface guidelines which you can look at here.

I had to add two strings to my info.plist file. In order to do this, open up your iOS build generated from your Ionic project in Xcode.

Search for info.plist in your directory search panel:


And add these two strings with your custom location permissions message

  • NSLocationWhenInUseUsageDescription
  • NSLocationAlwaysUsageDescription

After I added these custom messages my error modal looked something like this:

This fixed this initial rejection.

The second issue caused me the most trouble. Apple informed me that there was a second modal showing after the user already accepted the first location permissions one.

As you can see from above, the modal was giving a uninformative output path as my app name, which Apple deemed unfit for a user to see, which is fair enough as its a bit of a eyesore for the user.

This was not a custom made modal so it was coming from a native plugin, turns out it was one of two reasons

  • My Ionic Native Geolocation plugin was outdated
  • The Geolocation plugin was not correctly put into my iOS build output.

When you have added a plugin to your projects config.xml file, it won’t necessarily build into your platform of choice when you run the build commands.

These are the steps I had to run to rectify this:

So now our Geolocation plugin is updated with the latest version and with a custom location usage description

Next we need to remove our iOS platform:

Then we need to save all our plugins:

Adding the iOS platform back in now will also add in all our saved plugins from Cordova:

To make sure you now have the correct plugins run the command:

And compare that list to the plugins in the your build output folder:


These were the two obstacles I had to overcome to get Coffeetrail in the iOS store. Feel free to try it out and give feedback. As I’ve mentioned already it was rejected twice. On my third submission there was an extra processing time so thats something to be aware of if you want to be extra careful when submitting after that. Took an extra 4 days to be looked at.

I feel after finally submitting it I’m ready to undertake a React Native application.

Keep posted!

Want a job in web development? Learn a framework.


When browsing information about web development careers you might stumble upon junior or entry level developers asking about the correct way to get hired. Very frequently there will be advice given along the lines of:

  • Learn pure JavaScript.
  • Know the ins and outs of Vanilla JS.
  • Do not learn a framework until you know the intricacies of JavaScript.

And while I think all this advice is coming from a good place, its not practical.

This is somewhat of a controversial opinion when looking at online forums such a reddit webdev or reddit JavaScript. But lets take a step back and look at the facts here.

You are a junior developer with basic knowledge of JavaScript, you look at job postings online, what do you see?

Well, nearly every frontend position is looking for you to work with either Angular, React or Vue and no position is seeking someone proficient in vanilla JavaScript.

So if you were being practical, you should jump into one of these frameworks and learn how to use your basic JavaScript knowledge within the constraints of that technology. Doing this alone could increase your employability significantly.

Not Encouraged

But why is this considered a bad idea by the masses? Well it conflicts with the idea of what a good programmer should be about. The idea of what a web developer should know in order to give themselves the best chance possible to use deep knowledge that allows to debug and problem solve in the most efficient way possible.

But again, as much as I agree with this, its not practical for someone who has just entered the industry, is urgently seeking a junior position and who has possibly switched his/her career halfway through. This also applies someone who has just finished a bootcamp

Experts in the web development community have every right to demand high standards of programming, this is a highly skilled field that people devote massive amounts of time to and something they are truly passionate about it. But people entering the industry don’t have to brush up their JavaScript to the degree expected by most purists.

Why would someone in this position spend all this extra time going in depth in vanilla JavaScript when they can learn how a framework works and be able to code inside the context of this framework and land themselves a job as soon as possible.

You have to remember this isn’t someone who wants to adhere to the best coding practises currently available, at least, not yet in their career.

The most likely situation is that this person will come to terms with some of the key elements of JavaScript while working inside their chosen framework. From this point, he/she can then become proficient in the more in depth parts of the language.

Now let me stress, this is not ideal for the industry nor does it strengthen the quality of developers available to the workforce. But to deny that this isn’t the quickest surefire way to land a frontend entry position is foolish.


We can tie this back down to one of the most essential programming concepts, abstraction.

The latest of these in demand frontend frameworks give us a layer of abstraction to work within. This layer of abstraction is supposed to provide us with a new environment to work in, while hiding the previous complications behind the scenes.

This is exactly why a junior developer can begin learning inside the constraints of this framework, and improve their JavaScript while doing so.

Will they become an expert in JavaScript this way? No of course not, and this is the flipside of working in a abstracted environment. It hides the complexity that you could otherwise learn.

Another aspect that has to be considered  is how the latest frameworks are integrated with the latest in JavaScript practises.

Frameworks like Angular, React and Vue have standardized the use of the latest from ES6. This further adds to the argument, that you can easily jump into these frameworks and learn current and key fundamentals of Javascript.

Features like ES6 arrow functions:

Ternary operators

State Management in React

Anyone who uses these features will inadvertently broaden their knowledge of JavaScript and become more attractive to employers.


We also can’t ignore the dominance of external recruiters in the web development industry. I know from personal experience, as I’m sure many others  do, that these recruiters are hounding individuals with specific criteria ie, which framework do you know?

And while normally I’m the one complaining about the lack technical knowledge that a recruiter has, this is something that someone at entry level can take advantage of and be fast tracked to an interview.

Learn a framework, build a few small projects and you’ve already launched yourself into better position than you rightfully should be. You have to remember that the application of a language will be almost completely be inside the boundaries of the framework. Everyone will tell you that you can’t learn JavaScript this way but disregard these notions as if you are in the start of your career its only logical that you will learn as you go along.

A lot of the community will disregard this idea and I myself can see how it initially devalues the quality of junior developers but I like to be realistic and practical about these things.

Simply put, specialising in what people are looking for fast tracks you to a job and at the end of the day, landing that initial job can be the first step in developing your technical ability.

Technical prowess will come later, launching your career is paramount.

How to use Firebase to host your Web Application using a custom domain


In comparison to a few years ago, there are a wide variety of ways to deploy a web application. Many will vouch for Heroku for prototyping and I tend to agree. Its a great service to deploy an app free of charge with the option to pay for premium features to scale up.

Another great option would be Github Pages which allows you to host a website or web application by deploying one of your repositories. It gives you a url to view your repository such as :

Again, this is another great option for getting you application live.

The best option that I have been using at the moment is Firebase hosting. Its similar to the other options but allows you to stack extra services on top such as cloud functions. Heroku, of course, also lets you run similar server side functions and its backend and is a lot more flexible.

And although I might come back to compare all these providers the main thing to take away from these services for the purposes of this post, is that Firebase automatically provides SSL encryption. This makes it very easy to link it to a custom domain purchase from domain name sites. In my case, it was NameSilo, who I find dirt cheap without the shadiness of other low cost domain providers. Its reliable with a great albeit uninspired interface.

This is all taken from an experience I had when deploying my random beer finder web application.

This is an application that uses some nice animations from a frontend Coursetro tutorial in combination with RxJS Observables and requests to BreweryDB API.

Be sure to check it out here.

So lets deploy our web application and apply our custom purchased domain.

Setup Firebase

Full instructions from the Firebase documentation are listed here, however I’m just going to cover installing it via NPM.
Run the following command in your console window to install firebase tools globally:

Now, in the directory of your desired project, you now want to initiate hosting for Firebase:

From here you can dictate how you want you Firebase application to be configured.

Say yes to public directory and configuring as a single page app:

You should then create your project in the Firebase console here.

You project has now been initialized with Firebase. Once you are ready to deploy move onto this next section.


When ready to deploy your Angular application to Firebase we want to build a production version of it.

Run the command:

You application will be built and the output is usually in the dist folder. You can now do a full firebase deploy with the command:

Or if you just want to deploy the hosting services

When finished your console will indicate what url your deployed application is being hosted.

In my case it was something along the lines of :

Custom Domain

So the final step in this process is to verify your purchased domain to Firebase. Firebase will also take in any other subdomains you might have and redirect it to your deployed Firebase app url.

We will need to navigate to the Firebase hosting console.

You will have to change the DNS records in order to indicate to Google that you own the domain name. We want to create a TXT record in our domain backend. This is made relatively simple in NameSilo and most other domain hosting interfaces will be quite similar.

Log in and navigate to the domain manager:

Select your desired domain and click the DNS Records option.

From here we want to add two TXT record with details from our Firebase console.

After about an hour Google was able to recognize these new records and establish that I was the owner of the domain. Google will then ask you add two A records with custom IP addresses that they will give you. From here we will do the exact same thing on your domain provider except adding two A records instead using the details from our Firebase console.


As you may be aware, a typically bundled and deployed JavaScript web app using a modern web frontend framework is not crawlable or index able by most search engine bots.  To solve, it can be a complicated beast, especially for Angular applications.

The most common approach in order to make your Angular app SEO friendly is to allow your server to generate your HTML markup dynamically. In some cases, this can be easier said than done and was mostly done with Angular Universal.

However, I found it needlessly cumbersome and I think I have found a great alternative specifically for Firebase hosted applications. The folks at Angular Firebase have come up with a fantastic tutorial for this using Rendertron. An external service that allows your site to serve dynamic SEO friendly markup only to search bots while serving your users the standard JavaScript version.

I really think this is the future of SEO for web application so I highly reccomend you watch this video.


Its proven relatively pain free process to transfer a domain name over to our hosted web application. This seamless process is one of the reasons I’m looking at Firebase Hosting more longer term. Apart from just hosting, there are many other added features such as cloud functions which are particulary useful for deploying server side code alongside your application. I hope to cover that soon.

Comparing Package Managers – Whats the best for you?


A package manager is regarded as a collection of software tools that automates the process of installing, upgrading, configuring and removing computer programs.

The concept of using a package manager is no longer new to the web development community. In fact, we are now 5 years+ into a cycle since package mangers such as NPM have been introduced.

And with that introduction they have brought with them their own quips and hazards but generally speaking they have much improved our development lives.

The ability to keep a package frequently up to date is worlds apart in comparison to how JavaScript developers used to manually re-include an updated script into the header of their websites or application.

As well as this, the barrier to entry of someone in the community wanting to publish their own package or plugin has been significantly reduced leading to more packages being available than one could possibly comprehend learning about.

In this post, I want to compare the main package managers available to you and how they differ from each other and which one is most appropriate for the stack your using.

You might also want to check out this learning resource for all things Node.js.


Yarn is Facebook’s own published package manger and with it promises fast, reliable and secure dependency management.

It has quite a good system of caching dependencies. You might think that this seems like something that all package managers should have but its particular powerful here as its allows one to redownload packages offline.

This allows for continuous development while not having an active internet connection.

Yarn can be installed with npm and replaces npm in your terminal.

Or on OS you can install it using brew

Yarn also prides itself on its speed and up until npm5 was released it really had the advantage.

Now, both package managers are alot closer to each other when comes to measuring install times. Have look at this comparison here for more detail.

The speed differences between these two now are less significant and most users really won’t be able to tell the difference. But there are other differences with npm5 which leads us into the next package manger.


The most notorious package manager, NPM (Node Package Manager) would be considered the most familiar for those within the dev community.

It impresses by being the biggest software registry in the world and also being the most JavaScript focused.

The npm team was also able to address some of its shortcomings with the release of npm5 back in May of this year.

These changes improved its speed significantly while also adding default lockfiles which enable all npm installs to be reproducible.

This means that previous discrepancies between users on different development environments are no longer having differing experiences with the same install

What may have previously thought as a bug was rather just two different versions installed of package. This has been rectified now.

As a JavaScript developer you can’t really go wrong with NPM, its CLI is simple to use and it might just be the most user friendly option out of all the package managers.


Perhaps one of the most interesting package managers on this list, Turbo is a new NPM client that functions inside the browser. It claims to be 5X as fast as NPM and Yarn and you can look at its release post here.

Since it runs in the browser its predominantly used for Web IDE’s such as StackBlitz. One of the benefits claims to reduce the size of your node modules by half.

This is definitely one to watch as Web IDEs become faster and more reliable.


NuGet deals with all .NET assemblies so it is a very Microsoft focused package manager. It supports .NET native packages written in C++It is seamlessly integrated with Visual Studio and comes pre-installed with it.

It is generally thought that it is inferior to the latest versions of Yarn and NPM in terms of user interface, speed and performance. However, it still contains a large repository of packages with a focus to distribute server side libraries. Any releases from Microsoft are usually distributed on Nuget too.


Bower was originally created to be a specialized front end development package manager. Since then it has been made somewhat obseltete by changes to npm3 and Yarn.

While some have gone as far to consider it legacy, its quite dated in terms of functionality. It still meets the need of being a package manger but thats about it really.

Some have even called to see it depracted in order to make way for and encourage NPM + Webpack/Browserify workflows. You can have a look at that here


As with all branded tools for web developers there can by a lot of blind loyalty to one specific technology or in this case, package mangers.

From researching different aspects of whats out there I really don’t think any developer will go wrong choosing between NPM or Yarn. They seem to be the most feature rich of whats available and its very unlikely that you will need one over the other in your workflow.

Hopefully this cleared up some of the confusion around what package mangers suits your needs. I intend to update this blog a lot more regularly for 2018 while also getting the web app version sorted this month.

Stay tuned.