“Borderline bulletproof” security for API keys

In episode 5 of my Keep in Touch podcast I shared some thoughts on how I currently think about protecting credentials, API keys, and secrets (summarised as keys for the rest of the post) for 1st and 3rd party services and APIs. This blog post is a recap of those ideas and also a call for feedback and input from you.

The risks

The problem I am talking about addressing, is related to the fact that many applications embed keys in their binaries. These keys are required to authenticate (and authorise) the app, the user, or both with remote services. These services could be public or private APIs. Similar considerations apply if these APIs are 1st party or 3rd party.

If these keys are bundled with the app, a nefarious attacker could extract them and then impersonate the developer.

It’s not my intention to teach bad actors how to execute their plans, but I do want to give a few examples of some attack vectors that could lead to sensitive information falling in the wrong hands:

  • the nightmare scenario: the attacker could run a man-in-the-middle attack by running a WiFi hotspot or could be operating one of the nodes on the internet between the device and the APIs the app connects to
  • the easier than you’d think scenario: the attacker could run an on-device proxy (such as the brilliant Charles for iOS app that I use daily for non-nefarious reasons), and monitor all traffic
  • the attacker could grab the app binary (ie. apk or ipa) and do a string search for key-like strings
    Any of the above could lead to the attacker obtaining the keys that the app uses to authenticate itself against remote servers. Once they get these keys they can start impersonating the app and its users.

The hypothesis

I believe that by not including any keys in the app’s binary and by provisioning these credentials only via a channel owned by the operating system that uses SSL pinning, the risks mentioned above can be reduced or even avoided.

SSL pinning is essential in order to prevent an attacker from inspecting the traffic between the client app and the remote endpoints.

Animated GIF showing the way keys can be securely transmitted from cloud to app to server. This flow is described in detail below

This animation attempts to illustrate the approach I am suggesting:

  1. Provision the app without any keys
  2. Attempt to detect if the app is running on a jailbroken / rooted device, and bail if that is the case
  3. Upload the necessary keys to the Trusted Cloud provided by the Host operating system (i.e. CloudKit for iOS apps) using another app (i.e. console, browser, etc)
  4. Enforce read-only access to these keys for the client app
  5. Upon (first) launch, fetch the keys from the Trusted Cloud
  6. If the keys must be stored, only store them in a keychain or in a secure enclave
  7. Use the keys to communicate with the Server using an SSL pinned connection
  8. Should the keys become compromised, they should be replaced, and the client apps should naturally fetch the new keys. For this reason, getting the new keys should not require the previous keys.

The steps above rely on the fact that the mobile OS provides a cloud service that uses SSL pinning in order to communicate to the client apps. Without it, there cannot be a secure key provisioning mechanism and the entire flow falls apart.

The checklist

Often times the security considerations come in “late” or “after the fact”. To assess the state of affairs, and to add more protection going forward, I would go over the checklist below:

  • Limit the number of people who have access to the credentials. Replace the credentials when these people leave the job.
  • Never embed the keys in the codebase
  • Never grant the build (or distribution) servers access to the keys
  • Only trust the cloud service that belongs to the platform vendor for your app (i.e. CloudKit for iOS apps, Firebase for Android apps.)
  • Avoid storing the keys anywhere (on the device) unless really necessary
  • If the keys must be stored, then the only acceptable place is the Keychain
  • Avoid bundling black-box libraries. If the libraries use networking, inspect all networking traffic
  • Do not use a 3rd party networking library unless absolutely necessary. Always check the source code of such libraries
  • Never be the largest consumer of any one technology, framework, or library
  • Only load the keys at the code level that really needs them. Do not pass them through the business layer, particularly if there are 3rd party analytics or logging libraries bundled with the app
  • Obfuscate the code and avoid obvious naming strategies for the keys
  • Check the app’s signature / hash or anything else similar that guarantees that the binary has not been tampered with
  • Be mindful of jailbroken or rooted devices but never change the code in order to support them
  • Do a quid-pro-quo vulnerability analysis with a trusted partner (make sure dinner or beer is something at stake if an issue is found)

If you have more to add to this list, I would love to hear from you!

Closing comments

I think of myself as a security minded person, but I am by no means an expert. I offer no guarantees that implementing the steps above is going to remove or prevent any security related problems for a system I have not seen before, but, based on my current knowledge, I do believe it is the closest thing to a “borderline bulletproof” approach to securing keys and credentials that native apps use.

Lastly, I sincerely hope that, if you read this and have identified a flaw in my reasoning, or if you can spot an oversight, you will share with me (ideally with a solution in tow) so I can update the article.

How to turn a Podcast RSS feed into a website

As I wrote previously, getting started with a Podcast can be very straight forward. Todd and I wanted to add some personality to our show’s online presence, so we decided we needed a website. A lot of the information that would normally go on the website is already available in the Podcast’s RSS feed, so I started thinking about a way of not duplicating this effort. The Keep In Touch show is a hobby, and given how busy (and lazy) I am at the moment, I needed a pragmatic solution.


KeepInTouch.fm runs on Jekyll and is updated every time we publish an episode using our fork of the Jekyll RSS importer. We upload the episode and its metadata to our Podcast host and then we point the importer at the Podcast RSS feed. If needed, we customise the blog post and then push it to GitHub. GitHub pages then automatically updates the website.

List of requirements

We wanted the website to provide some fairly basic functionality:
– general information about the show, and a the ability to subscribe to the Podcast
– a blog/website where each episode can have its own page
– each episode page would need to privide visitors with the ability to listen to the show, and to find shownotes, links, and other relevant information

As the administrators of the website, we would need:
– a modern website: responsive, fast, and secure
– an easy to maintain set up (i.e. no hardware / software maintenance)
– a simple updating mechanism
– a simple way of transforming the information we had already provided in the Podcast’s RSS feed

The solution

GitHub Pages was the first option we considered, and luckily it ticked all our boxes. We quickly set up an organisation and picked a simple, but quite configurable jekyll theme for the site.

The only friction I still had to deal with was the “transformation” of the Podcast RSS feed into blog posts on the site. Jekyll does come with an RSS importer, so I gave that a go. Most of the metadata was extracted nicely, but there was no way to play the show without changing the post manually to link to the mp3 file that was actually available in the RSS feed.

Open Source FTW

Luckily, the Jekyll project is open source, which meant I was able to fork the RSS importer, and turn the RSS audio enclosure into an HTML audio tag. All it took was 13 lines of code.

The result

Today, my workflow couldn’t be (?) simpler:
– Record and edit the show
– Upload the episode and it’s metadata (i.e. shownotes) to the podcast host
– Run a simple script to fetch the new episode (and turn it from a feed Item into a blog Post)
– Push the new post to GitHub

If you found this post useful, please consider subscribing to KeepInTouch on Apple Podcasts, Google Podcasts, or wherever else you listen to podcasts. If you like what you hear, please leave a review. Lastly, please send us your feebdack via email or twitter @KeepInTouchFM.

The free and easy way to start a Podcast

Setting up a Podcast in 2019 can be fast, free, and painless. More importantly, the distribution and maintenance of the show can be (almost) fully automated. This post covers the steps I took to launch KeepInTouch.fm together with my co-host, Todd.

MVP – Minimum Viable Podcast

  • First we decided what our show is about. Keep in Touch covers topics from two main areas: Apple/Google tech platforms, and raising kids
  • To solve the hosting and publishing of the show we set up an account on Anchor.fm
  • Lastly, we recorded and published the show

That’s could’ve been the proverbial it, but since both Todd and I are tech people, we were not satisfied, yet. Why not? Because of the details…

Past the basics

We wanted the show to have a home that we could customise, personalise. We also wanted to be able to understand and interact with our audience. To achieve this we made did a few more things:

  • We put a little effort in the show artwork, we created chapters for the shows (chapter artwork and web links when appropriate), and we collected and published thorough show notes.
  • We recorded and edited the audio outside Anchor, and only published the mastered audio. It’s not perfect but it’s definitely less *rough*.
  • We bought a domain and we set up a website: KeepInTouch.fm.
  • We set up a Twitter account: @KeepInTouchFM.
  • We set up a vanity Google Alert for our show title and website.
  • Speaking of vanity, we created a Chartable.com account to keep an eye on how the show is doing in the charts (we were #7 in the Educational Technology category at one point!).
  • We transferred the ownership of the Apple Podcasts and Spotify feeds.
  • We set up the Stitcher and TuneIn feeds ourselves.
  • We integrated the podcast RSS feed with our new website: once we publish a show, a corresponding blog post gets created (almost) auto-magically.

Some of these enhancements will be the subject of future blog posts.

Things we learned

  • Apple Podcasts took about five days to process Anchor’s request to list our show.
  • Google Podcasts approved the show almost immediately but took about two weeks to actually make it available to listeners.
  • PocketCasts picked up the show immediately (most likely due to an integration between them an Anchor).
  • Anchor didn’t seem to get the show listed in TuneIn so we had to list add show manually.
  • Anchor doesn’t actually support all the podcasting networks.
  • Hosting the show’s website on GitHub pages was straightforward but did have some limitations. We forked Jekyll-Import to add support to the Jekyll RSS importer for Podcast RSS feeds, so we needed a home on GitHub. Hosting the website itself on GitHub made sense since Git enables a simple way to publish new episodes / blog posts.


  • Hosting and publishing the show: Free.
  • Hosting the website: Free.
  • Having a custom domain name: same cost as for any other type of website.
  • Podcast recording and editing tools: Free (not really, since we decided to use our own microphones and Digital Audio Workstation).
  • Time required to record, edit, and publish the show: 1 hour for the recording, 4 hours for editing (takes less and less each time), 30 minutes for packaging and publishing.

We are four episodes in, and we are having a lot of fun. I hope you will give our show a listen and let us know what you think. Keep in touch by subscribing on Apple Podcasts or Google Podcasts.

Apple Wishlist from a New Zealand Customer

I live in Wellington, New Zealand and I own a truckload of Apple products. This is my wishlist of things I wish Apple would start doing.

iPhone & iPad

  • Visual Voicemail. I get that it may be up to the telcos, but I’d love to know that lots of pressure is being put on them to add support for this feature.
  • TV app
  • #images support for iMessage when the preferred language is Te Reo.

Apple Watch

  • LTE. Again, I realise it’s probably our telcos being slow to update their tech stack, but I wonder if they get the same lead time as their Australian counterparts.

Apple TV

  • TV app. Once you use it, it’s hard to go back to another interaction paradigm.
  • Siri support. Guess what, Siri understands us even when we use an Australian Apple Id and a cheap VPN. How come we have Siri on iOS, and watchOS, but not on tvOS? Even Siri on macOS works…


  • Surely they know we use the same plug and voltage?!

Grab bag

  • Apple News. I am a registered Apple News Publisher, I can see Apple News in the Today View, so why can’t we have the News app?!
  • Public Transit support in Maps (thanks for Flyover, though).
  • Ability to purchase TV Shows.
  • … an Apple Store. Sending Macs and iOS devices to Sydney for repairs is super painful and not very well aligned with the Apple Green strategy. Authorised repair agents often can’t help (e.g Apple Watch is a no go).

What have I missed? What’s on your list? Head off to twitter to tell me how naïve I am.

A Recommendation for the Air New Zealand Customer Carbon Offsetting Programme

Air New Zealand has a Carbon Offset programme and that’s a really good thing. I wish it was more attractive to flyers, though. If you don’t normally offset your flight’s carbon footprint, I’m curious to hear if the changes I propose below would make you more interested in participating in this programme.

At KiwiFoo this year I spoke to a few smart people and asked them if they offset their carbon footprint when flying Air NZ. People looked away, shrugged, and shook their heads. When asked why, their answers were a variation around the same theme: it felt futile, and a bit of a waste of time and money.

The rest of this blog post details how I believe this programme can be rejuvenated. I believe more people would participate in the programme if they felt appreciated and rewarded.

Real benefits

People are asked to spend money in order to offset their flights. There is even a calculator for that.

The offset cost for a return flight from Wellington to Auckland, as far as I know, can be as low as $2.49.

Wellington to Auckland Carbon Offset Cost $2.49 In return for that, what you get is just a good feeling. And that should be enough. But it’s not in our human nature for an anonymous good gesture like that to become the norm. What humans need is rewards, or, as we like to call it nowadays, a strong value proposition.

What if, upon paying to offset the carbon emissions, flyers get the following in return:

  1. A bag tag (or an insert in the vein of the orange priority tag that Star Alliance Gold members receive) that makes the bag stand out. How about a Pohutukawa insert that flyers can pick up somewhere near the check-in machines? This would be very similar to how Electric Vehicles often carry a blue badge.
  2. Luggage priority (value!). That would require the creation of a middle tier in luggage processing. Orange priority tags > Pohutukawa tags > Regular.
  3. Upweight for OneUp.  Currently, these are the upweight tiers: Elite – 50%, Gold – 30%, Silver – 10%. What if Pohutukawa was 5%?
  4. A creative, community designed, visual representation of the flyer’s aggregate contribution on the Air New Zealand website and apps.

Peer pressure

When other travellers see repeatedly the Pohutukawa Bag Tag insert, they may become curious with regards to what it represents. They may even learn more about the programme, and they may be encouraged to try it.

For each flight, let all the flyers see how much of the carbon footprint has been offset. Visually, that could be as simple as colouring in an Air NZ plane. Better still, maybe there is a way to produce a heat-map of the plane showcasing where the carbon offset spending occurred.

When there is a positive offset (ie. more carbon was offset than produced), then maybe there can be a new form of reward for the fliers who contributed (e.g. discount on the carbon offset cost of their next flight).

Closing notes

I’m secretly hoping somebody from Air New Zealand comes across this blog post and it inspires them to look at the Carbon Offset Programme once again. Is it producing the results that they were hoping it would? Are there ways to make it more attractive to flyers and to encourage them to contribute? I am a Star Alliance Gold member, I fly a lot more than I’d like to, and I often forget that this programme exists.

Improved – Get everything done

Over the past two years I have been working alongside my friend (and co-founder) Stef on Improved. Yesterday evening we released the first version to our friends and family.

I won’t go into what Improved is because its website covers all that; this post exists so that I can mark the moment when this all happened. Suffice to say, our vision is to

Remove the guesswork from finding the right person for the job

Some background info

People who know me closely are aware of the fact that I am a big fan of the Lean Startup model. Yet I just said that we’ve been working on this project for a couple of years, thus contradicting my previous statement.

Here’s my excuse: I have a day job, as Head of Mobile at Trade Me, and this job takes up at least 4 days of my week (sometimes I take work home with me). On Tuesdays however I get to work on what I am passionate about. For the past couple of years I have been spending my Tuesdays juggling work on Improved, with some other client work (for my boutique consultancy called Tmro), and with some other family activities.

This dynamic has kept my brain engaged at 100% and has produced an incredible amount of work related satisfaction (be it Improved, Tmro, or Trade Me). Without a doubt, all these companies / products have benefited from the experience I accumulated while working on the other ones.

Improved is the most recent initiative of this bunch, therefore it took a lot longer for the fruit of the work done on it to show. That ends today.

All in all (an including evenings and weekends) I’ve spent between 4 and 6 work-months building Improved. I am not counting here the effort and work poured into the project by Stef, who’s been doing a bloody awesome job in a similar 1 day a week arrangement for a period almost as long.


We decided to ship our MVP at the point where the platform supports the use cases we considered to be necessary (after doing plenty of soul searching and chatting to other people).

Roughly, these are the “features” of our v1:

  • The simplest possible create and manage Job flow
  •  Support two way messaging and quoting (including Push Notifications) between job owners and service providers (aka Improvers)
  • Search and browse Jobs and Portfolios
  • “Smarts” that support our vision:
    • photo doodling
    • take similar photo assistant
    • before and after comparison tool
  • Social login and straightforward account creation
  • Seamless Native app to Web handover
  • Clear feedback/review process

Apps side by side

Could we have done more? Absolutely! Our backlog is chocka full. Should we have done more? We think not. We want (and need) feedback from our users so that we shape the product into something that people love using.

After the first few user interviews we realised just how differently people think of their interactions around a job. Waiting longer and shipping a more “feature rich” product would basically mean increasing the number of assumptions made. This is a risk we chose not to take.

The next steps

Yesterday we started inviting Beta testers to use the app. We hope that everyone who uses the app (whether they have jobs they want done or they just look for their next customer) will find it useful.

We have an Android app underway, as well. I will shift my attention to finishing that app, while supporting the “early adopters” with anything they may need.

I’d love your help

If you’re reading this, chances are we know each other. Hi! You can help too! Get in touch with us by email and we will add you to our Beta test group. Improved is free for everyone to use, and posting jobs is non commital until you accept a quote (just like in real life).

Here are some other ways you can help:

  • you can upload DIY projects you have already done. This way we can learn more about the types of jobs people do, and the language they use to describe them
  • next time you need to mow the lawn, or prune a tree, or take classes or lessons of any sort, post a job on Improved. It’s free and you can build a pretty neat portfolio that you can be proud of
  • visit our website and send us any feedback you can. Is is clear what the product does? Do you like / dislike anything? Do you have any recommendations
  • spread the word. We have a Facebook Page, a Twitter account, and a Website. Please send our way all the to people you know who need stuff done around the house, who used a dog walker in the past, who took lessons or classes of any sort. Our mission is to enable people to be the best they can be at what they do.

Thank you.

Cocoaheads Members on a Plane

Playgrounds – The story behind our group picture

After attending the Playgrounds conference in Melbourne, I was on the Air NZ 850 flight back home to Wellington together with several other Cocoaheads Wellington members. Prior to boarding, we talked about taking a picture on the plane that we could use both as a backdrop for our website and also as a “thank you” picture that we could send to Andyy Hope and the Playgrounds crew. That idea (and the process of taking the picture) almost gave a poor woman a heart attack.

Here’s what happened: before boarding the plane I asked everyone in our group if they were keen to take a picture together mid-flight. Everyone was “on board” with the idea, and because I was seated right at the front of the plane, I took the first opportunity and I asked the flight attendants if it would be okay for us to take a picture after they had finished with the food-and-drink service. The flight attendants confirmed that it would be okay so we proceeded with the plan.

We used the in-seat communication channel to chat to each other. I was talking to Sam, Tim was talking to Raj or Max, you get the idea. Giggles ensued as Tim suggested that maybe the pilot could join in on the photo, since the plan would surely have an auto-pilot feature. Since we were all scattered around the plane, getting out of our seats was going to be a bit tough and even crawling under the seats was considered. Silly stuff.

The flight was smooth and the food and drink service went by quickly. Once the aisle was clear I stood up and I made my way to the back of the plane. As I approached someone from our group I’d lean over and say “We’re doing this now. Come to the back of the plane”. The first person stood up, then the next, and eventually I reached Tim. He was seated in a window seat right at the middle of the plane. Soon everyone had stood up and assembled at the back of the plane, as per our plan.

I gave Julie my iPhone and asked her to shoot a few photos. She took some pictures of us smiling, and some other photos of us attempting to make the letter “P” (for Playgrounds) using our fingers. We were smiling, giggling, and we were completely unaware that a flight attendant had stopped next to where Tim used to be seated.

Minutes later we started making our way back to our seats but the flight attendant that had stopped next to Tim’s seat was now chatting to him at the back of the plane. A few of us looked back and we didn’t quite understand what was going on so we went back to our allocated seating.

It would all make sense to us later on. After going through the security check, we regrouped and Tim told us what had happened: as he was messaging using the in-seat entertainment system, the woman next to him caught glimpses of words: “…pilot…”, “…auto-pilot…”, “…under the seat…”, “…back of the plane…”, “…after dinner…”. Then she heard my say (in my Eastern European accent) “We are doing this now”, and then she saw a couple of men follow me and the one next to her excuse himself to join us.

It’s easy to see how all those pieces of information could form more than one puzzle (ie. taking a funny picture for our new Melbourne friends) so she rightfully summoned a flight attendant. Luckily I had already informed this particular flight attendant of our plans and she could see us setting up to take a picture so she was able to reassure the worried passenger that it was just a misunderstanding.

I’d hate to think what would have happened on a different flight, with a different crew. In hindsight I smile, because the woman seated next to Tim laughed it all off. But I wonder if I would have had a heart attack, had I been in her place.

In conclusion, thank you Andyy Hope and the Playgrounds crew for a fantastic conference. We all got back home safely and, to the best of my knowledge, nobody was hurt while taking the picture attached to this blog post.

Do you want to own your status updates?

After backing Manton Reece’s microblogging kickstarter I decided not to wait any longer and setup a MicroBlog section on my website where I would keep my short form updates. This post covers my goals and the approach I took to achieve these goals.


There are just a handful of things that I thought I’d need:

  • I own my content. I don’t mind posting to Twitter (or Medium) but the canonical location for my content is my own website
  • It’s easy. I can easily separate short form content (ie. statuses) and long form writing (ie. this post)
  • I still engage via Social Media. I can publish short form updates to my own website, and then the entries get cross-posted to Twitter
  • I  can post from my iPhone without needed to make edits from WordPress before publishing


I tried a few approaches (involving a range of apps such as IFTTT and various WordPress plugins) before I settled on the approach below.

It’s easy to own my content

My website is currently running on a self-hosted WordPress installation. There were two options here:

  1. I import all my Twitter posts under a special Category, or
  2. I post on my website first and then cross-post to Twitter

Option 2 feels more like “doing it right”, and, should anything go wrong in my setup, I never lose any posts I made from my own website.

What I decided to do was to:

  • create a new Category called MicroBlog
  • update the Menu to include this new category
  • replace the stock RSS widget with Category Specific RSS and use it to surface the MicroBlog RSS feed into the side bar
  • exclude the MicroBlog posts from the main page using the Ultimate Category Excluder plugin
  • make all posts in Category use the post format “status” so they looks consistent and timeline-like
  • remove all extra post decorations (ie. sharing) from the list of posts, but leave it on the post page itself
  • not use a post title, in order to mimic a status post more accurately

With these changes in place I ticked the first couple of boxes. What was left was to sort out cross posting to Twitter and publishing while on the go.

Sharing status updates to Twitter / Social Media

Posting to Twitter proved to be more difficult than I thought it would be. The obvious way, via Jetpack’s Publicize feature, seems to share only the link to the post when a title is not present. Therefore I had to look for other options, although I’d much prefer to just use Publicize.

The choice I settled on is an IFTTT rule: “when a new feed item is added to parfene.com/category/microblog/feed post a new tweet to @nicktmro”. The issue with this approach is that IFTTT doesn’t have a smart way of appending a URL to the post when it is over 140 characters, so I was “forced” to append a URL to the original post. It’s not very tidy but the counter argument is that it drives traffic (and search engines) back to the canonical location of the status update.

Posting while on the go

I carry an iPhone and a Pixel with me all the time. Posting updates to my website is a task I assigned to my iPhone.

I seek speed and simplicity when it comes to capturing my thoughts, which is why I use Drafts for almost every form of text capturing. This text sometimes ends up in iMessage, or in OmniFocus, or in an email, or in my Clipboard, or in WordPress… You get the idea.

I looked at the existing Drafts actions but I soon realised that I needed to be able to post exiting text and snippets, too. I needed an extension point. Enter Workflow. By delegating the communication with WordPress to Workflow I managed to increase the ways in which I drive content to my website.

Here’s how it all works:

  • I have a workflow that expects text input (or extracts it from the clipboard)
  • The workflow presets the WordPress category, post format, etc
  • This workflow is added as an action to Drafts

Now I’m good to go. When I choose to share my next status update all I do is go to my usual app (Drafts), write a snippet of text, and choose the Post to Parfene.com action.

Wrap up

I encourage you to try microblogging for yourself. My post is lengthy but you don’t have to do everything in one sitting. You don’t even need to fully automate everything, like I have.

This approach has made me feel more involved, engaged, and responsible with regards to the things I share with everyone. As somebody who oftentimes doesn’t count to five before he speaks, this should be a positive outcome…



Be Counted During Māori Language Week 2016

I want to ask all the people who speak or understand Māori to change the preferred language on their devices to Te Reo Māori at least for one day during Māori Language Week July 4 – 10, 2016. I emigrated to New Zealand in 2005 and I have loved this country ever since. My close friends know that I get emotional when I speak about the incredible difference living here has made to myself and my family. I’ve tried to give something back whenever I could, which brings me to this blog post.

What I want to achieve

With your help, I want to prove that there is a large enough group of people in New Zealand that would like to see support for Te Reo Māori in our software. Right now we are dealing with a vicious circle: businesses don’t see enough Māori users in their analytics therefore it’s difficult to prioritise implementing support for this localisation over other initiatives. I believe that we can help break this cycle by setting on our devices the default (preferred) locale to be Te Reo Māori.

You can help

Regardless if you’re a technical person or not, there are two things you can do to help: set Te Reo Māori as the preferred language on your device (even just for one day!) and then spread the word.

Step 1. Make Māori the preferred language on your device

Don’t worry:

  • apps and websites will fall back to English when Te Reo Māori is not supported.
  • this change will not update the language used by the operating system. It will however let apps present content in Te Reo Māori whenever they can. See the Google search screenshots below.


Do this from Settings > General > Language & Region > Other Languages (or Add Language if you already have more than one). Look up Māori and then select “Prefer Māori”.

Running a Google search for “Te Papa” will then produce the same results,  but the word “Images” has been replaced by “Atahanga”.

Google Te Reo

You may think it’s a worthless change. That would be true if nobody else makes the language change I’m encouraging you to make. The more of us do it, the more we move the statistic needle.


Android support is patchy. Unfortunately support for Te Reo Māori does not come out of the box for the official Android releases. If you’re lucky, your particular device may have Māori or Te Reo as an entry in Settings under Languages.

The good news is that Google Developer Group Wellington (which I founded a couple of years ago) has support from Google to put together an official Pull Request to Android that will introduce support for Te Reo Māori. Get in touch if you wish to help.


I need to disclose that I am not an active Windows user so the information below may be out of date. I do believe that Māori has been an option since Windows 8, though. Below you can see a couple of screenshots of what you need to do to express your preference.




Setting the preferred language on the Mac is also quite straight forward.

  1. Navigate to Settings and search for Language & Region.
  2. Ensure that your Region is set to New Zealand then click the + button under Preferred Languages
  3. Select Māori from the list. And click Add
  4. Select Use Māori and then restart your Mac

You’re (almost) done

Check here that you have successfully updated your language settings.

From this point onwards every time you use an app or website you will be counted. Ka pai!

Step 2. Spread the word

I believe the best thing you can do next is to just speak to people about this topic. It really helps with awareness and it’s more personal.

An easier option would be to send your friends a link to this article or to any of the resources on the internet that discuss this topic.

If you want to be succinct you may consider asking your audience: “Set your device’s language to Māori during Māori Language Week July 4 – 10. Help make Te Reo an option in the apps you love. #TeReoBeCounted”. You can click here if you want to tweet this message.

Supporting Organisations

A number of organisations have accepted to help this initiative in one way or another. There will be a follow-up post after this week is over to report on what we have collectively learned. Thank you Trade Me, Xero, Powershop, Radio New Zealand, KiwiBank, and Te Papa. If you engage with their apps and websites, and you have set Te Reo Māori as your preferred language, your voice will be heard.

1. Your apps count, too

If you build apps / websites targeted at New Zealanders, you can help, too. What you need to do is to share with me the number of users or sessions that you see for the mi_NZ locale, before and after Māori Language Week.

Here are a few options for how you can share what you learned:

  • Preferred: raw numbers. For example you could tell me Unique users on the 4th of July and on the 11th of July. You can check these numbers with most analytics tools anytime after the 11th of July.
  • Great: growth numbers. If you are comfortable with this option instead, then please share just how many of your users preferred Te Reo Māori on the 11th of July, versus the 4th of July.
  • Good: percentage change. If you’d rather not disclose the number of users who chose to start using Te Reo Māori, then maybe you can share with me what the % change was (positive or negative).
  • Nice: whatever you can tell me 🙂

Feel free to use (without the need for attribution) the instructions above to tell your users how they can go about setting Te Reo Māori as their preferred language. Get in touch with me if you want to continue the conversation.

2. Spread the word

Your organisation already engages with customers and this is a great opportunity to let the inner Kiwi show. You can break some of the BAU routine by educating your audience that Te Reo Māori is a viable language on their devices. You could take any of the following actions:

  • prepare a newsletter
  • write an announcement on your website
  • post on social media
    • Twitter.  “Set your device’s language to Māori during Māori Language Week July 4 – 10. Help make Te Reo an option in the apps you love. #TeReoBeCounted”. Click here to do it right now!
    • Facebook. Use whatever language you are comfortable with. Feel free to use the instructions above on how to change the language settings. Make it clear if your app/site supports or doesn’t support Te Reo Māori at the time of the post. Link to my blog post if it helps.
  • tell your front line (customer service, host and hostesses, sales, etc) about this initiative
  • update your showroom/store. Prepare and clearly label devices that already run Te Reo Māori. Train your sales staff and ask them to spread the word to your customers.
  • improvise

 3. Encourage your audience to engage

Now that you’ve spread the word, these users can be counted in the participating apps and sites. It would be a nice gesture to mention (wherever appropriate or by linking to this page) who else is participating in this campaign.

4. Post campaign

After the campaign is over, I will aggregate the results and I will communicate to the participants what we have collectively learned. I will then follow up with another blog post for the benefit of the community.


What drives me?

Aotearoa is my home. There are many other people, much more informed than me, who can probably tell you why doing this is a good (or not so good) idea. What follows is my personal view.

Kiwis are amazing. I love Wellington. Even the laws are pretty great when comparing with the rest of the world. All these things play a an important part in how I feel about this place. However I feel that the language does not contribute at its full potential to this sense of belonging.

What does a best case scenario look like?

With enough exposure, here’s what I hope this initiative will achieve:

  1. Make more Kiwis aware that Māori is a viable language option on their devices
  2. Help those doing software development to better understand the makeup of their Kiwi audience
  3. Long term, I hope to prove that investing effort into localising our apps to mi_NZ (Te Reo Māori) is not just respectful but can also have positive effects on the relationship between app builders and their audience
  4. Get localisation support added to the roadmap of as many apps and services as possible.

What about the Census?

According to the 2013 Census, there were 148,395 people who can speak Te Reo Māori. Unfortunately I cannot settle with this number. Here are a few reasons:

  • there may be Kiwis who, out of modesty or self-consciousness, did not claim to be able to speak Te Reo
  • speaking and reading are different things. The census asks about the former
  • some people who can speak Te Reo may choose to not use the language on their devices. It makes me sad, but I can definitely respect their choice
  • not all these people have devices that can show content in Te Reo and some people may have more than one device

In reality, we may never be able to know how many people prefer Te Reo. All I want is to show that this number is large enough to justify treating it as a priority in our apps.

What does “our apps” mean?

I am doing this as a community member, not as the Head of Mobile at Trade Me. By “our apps”, I mean the apps and websites of the entities (people or organisations) who participate in this initiative and wish to better understand their audience.

We’ve promoted this. Now what?

If you build apps or websites please start tracking the number of users and sessions that use mi_NZ (Māori, New Zealand) as their preferred language.

If the number of users and sessions goes over the critical threshold for your organisation, then it’s time to update your definition of “done” and include localisation to the new features and apps that you build from here onwards. Don’t forget to update your testing strategy to cover text input in Te Reo Māori.

I’ve changed my mind

On iOS, you can go back to the same settings screen and tap the Edit button on the top right. Then you will be able to remove the newly added language.

Kia kaha e hoa mā! (Let’s go team!)

Update 5 July

  • Clarified that when there is only one iOS language, the option reads “Other languages” rather than “Add Language…”.
  • Added instructions on how to remove the language on iOS if you have changed your mind