Gluon for Micro.blog

I'll be micro-blogging about Gluon dev throughout the day. So ignore me if it gets a bit too much. The last build runs out in around 15 hours, so let's see how far I get.

I spent nearly all day exclusively on Gluon. It's at 3 days to go until the last TestFlight runs out. I'm feeling somewhat pressured. I'm thinking of shipping of what I have on Thursday evening or Friday morning. It will have lots of features/functionality missing that is in the last build, however I think it's for the greater good in the long run.

I was thinking about this the past few weeks as it dawned on me that I will never have it ready in time with everything I had. Probably not the best thing to take away features/functionality...

After that, I will keep shipping updates as and when they are ready. All my TestFlight slots are full already, so I want to thank everyone for using Gluon! I'll be opening more spaces in a few weeks to give me some space to add a few more features/functionality.

I'll write a blog post about progress in the coming days. This, however, was important to say.

Who can guess what's not working correctly? 😉

Currently working on the HTML parser (I wrote that from scratch, like most the app) and image loading for Gluon. Debugging with Safari 🤩

17 days to go until the last build of Gluon runs out. No pressure! Hopefully I will have good progress over the weekend. Let's see.

The app already runs at least 3 times faster than the old one, so I'm pretty happy about that. Although I'll have to start adding all the features, that the old build had, back in. Worth it in the long term.

From this:

To this:

It's been 5 steps forwards, 6 step backwards, a few missteps and then back to square one. That pretty much sums up the development for Gluon the past few weeks.

It wasn't as such as a standstill, it was more a question of how and finding a perfect middle ground. Not to mention coming to the realisation that I am only one person, that also has clients, and that I won't have time to learn big new frameworks from scratch without spending considerable amount of time. I want something I can develop using a workflow I know and am comfortable with. I also want to be reactive to change and be able to make changes with ease across both platforms, reasonably quickly. I don't want to duplicate my work and I certainly don't want to be behind the drag curve (aviation nerds will like this saying!).

I realise that I said a few things about my gripes with certain frameworks and workflows, but the truth is... I work with them every single day! I feel like I'm in a unique position to make this work for me and get better at what I can offer for clients and of course for pushing forward with my very own ideas that I want to work on. So for me the developer happiness is that I work and continue to improve with the tools I work with every day... even though sometimes they don't line up with my personal standards or just annoy me.

Anyway... there are personal objectives and views and then there is reality. I'm happy to accept reality.

So, I can only apologise to be a flag in the wind the last few months!

A new beginning

The first version of Gluon ran across multiple platforms using React Native, which allows you to build native apps using Javascript. That's pretty cool (notice the change of tone).

Unfortunately version 1.0.0 was riddled with wrong doings since step 1. The official way to install React Native and get started is using a third party framework called Expo. Expo, on paper, is amazing. However, once you realise what it actually installs and how it locks you in... you don't want to ever touch it again. Last year I built a React Native application for a big client, using Expo as the starting point. It's a regret I/we have to live with! Sometimes the "quick" way isn't the right way, and it's certainly true here.

Gluon 1.0.0 weighed in at roughly 26MB on iOS and Android... and that's out the box!!! I haven't even added any single line of code at that point. For me this should have already thrown a red flag.

When using Expo, they'll add loads of unnecessary Android permissions that the app wants out the box. Yup, you can remove them... but the problem was that there were still many areas of doubt! This shouldn't be the default out of box experience. I don't need to know any precise information on location, or phone status, or access to contacts and and and. I'm not building a shady app. I'm building an app that users can trust!

Anyway, I took time to work on a super clean React Native build using the "old" way of installing a project. The installation and getting it to run was surprisingly easy. However setting the right direction on how I wanted to code and keep it all modular and easy to work with took a few trial and errors. It was painful and I did loads of researching!

I'm going to share some screenshots in a minute, which has some code running already, however the most important part is the build size of the app...

My pure native iOS Swift version that I shared a screenshot of the other day, weighed in at 12.8MB out the box with a few navigation controllers and the login screen. Not bad! Less than most websites for sure, ha!

Now, I've got the build down to 3.8MB! This makes me happy! I know that many people probably don't care about things like this... but I do!

Introducing the start of Gluon 2.0.0

Version 1.0.0 was a playground... I should have called it Version 0.0.1. Anyway, 2.0.0 is fitting and it marks a new beginning for Gluon. One that I'm happy with and I'm hoping that users will be happy with too.

I can re-use most of the codebase for Version 1.0.0 and bring it across to make progress quickly, however I'm reworking the lot. It's a great opportunity to do just that. Version 1 was built super fast in pretty much a solid one week (for most of it), which served its purpose! The code isn't bad, but it's not the best it can be. Sure, nothing is perfect but I can see how it can be improved greatly. Developer happiness, right?

There will also be finer enhancements with the UI and a better integration into the real native navigation controllers for both platforms. Version 1 used something called 'react-navigation' which is the recommended standard (again). Unfortunately it only emulates the navigation behaviour found on both platforms, there is nothing native about it. That means that speed and, most importantly, accessibility was and is, crap! Well... no more. Now I'm using the excellent 'react-native-navigation'. It was a bit painful to set up but well worth the time!

Screenshot time

Now that I hopefully set the tone... here we are at the humble beginnings once again. I spent the weekend working on getting the base screens set up, with their real navigation controllers. I had a few problems, but I finally managed to get past that hurdle... build and compile errors and what else not.

Here is the tab screen, after log in. Yep, get a shock, there is nothing there!

Android left, iOS right. Notice the difference in the tabs on Android? Yep... those are native and react as you expect on Android. That made me happy!

Something that wasn't possible before was listening for "viewDidAppear" events or "viewWillDisappear", you'll know them from native iOS development. Pretty handy! Out the box you would have to listen for "onFocus" or "onBlur" events on the window DOM, which was painful and never really was that good to rely on to clean up stuff like cancelling network calls or other things.

I also now have the ability to cache the current screen, the whole lot of it. So when you come back to the app, after it has been killed in the background, you'll get the most recent cached version which is followed by whatever I have to do to fetch updates and refresh the UI in a meaningful way.

With this set up, I worked on the login screen next - I took the existing design and ideas and tweaked it ever so slightly. I'll probably make it a bit more sparse.

The colours at the bottom are the Micro.blog shades of orange. However, I'll probably just create a small button under login that says "Create an account" or something easy like that.

That's the design done, so now I just need to reintegrate all the API calls and logic. I already have a solid way of doing it, so I'll probably use most of what I did.

Next steps and timelines

The next step is to work on the login and a nice way of displaying what is happening as you log in, something that I didn't really think about too much in v1. Hoping to have this done in the next few days including creating a solid foundation for calling the Micro.blog API.

Then, step by step, I'll be working on getting everything (mostly) into the app again. I'm conscious that the current TestFlight build runs out in about 26 days... and that there is no version for Android available at the moment.

It's my hope that I can get a build out that displays the timelines nicely and profiles within a few weeks. It won't have 100% of the functionality as per version 1.0.0 though. However, I'll be able to build them out relatively easy. Replying will probably be missing, but not for more than a week or so. Settings will also not be there for now as I rework some of the UI logic that plagued v1.

Anyway, just a huge thanks for all the nice emails and notes I received. I'm hoping that the app makes a meaningful contribution to the community in the long term.

Thanks for reading.

I'm working on the Gluon app for iOS at the moment, having fun with some emoji in the tab bar. I have the login screen working already (sending the login email). I love the colour of the header.

The past few weeks I took time to look at all my options with getting Gluon back on Android.

I wasn't happy at the end of last year on the whole process of developing the app with React Native... Starting from scratch with the bare minimum that is required to get the app running has been a breath of fresh air.

The app size went from ~27MB down to around 3 - 6MB depending on the device. On top, performance has been improved by some crazy number. I managed to remove all the bottle necks that crippled the earlier builds. I'm happy with this.

Also, when I first set it up it added CRAZY amounts of permissions that it wanted access to out of the box. If you noticed that in the Play Store listing then you know what I'm talking about. No more!

Saying that, I have a working build... unfortunately I'm having problems with the production build to run on a new device. Because... don't know!

I'll be starting a new round of "internal testing" in a few weeks, so if you'd like to get back onto the list please please please let me know as I'm starting fresh.

On top, I managed to add support for Android 7.1 upwards and have tested it all the way down to API 25.

Here are some screenshots of the build in action, enjoy them.

Just getting most of the Micro.blog API endpoints into PAW. I should have done this from the start!

And so it begins.

Yesterday I sat with Michal (@michal on micro.blog) and we had a quick talk about Gluon and my recent blog post explaining why I’d like to discontinue it for Android.

Whilst most things in this article are true, I had a change of heart!

So, instead of dumping it I’m going to be creating a special build just for Android. This probably won’t have feature parity of the iOS version, but will have most of the Gluon DNA.

I’ll be starting from scratch with a minimal build using what I know. I’ll take to heart performance and also use the minimal build tools I can use to get the best out of React Native and Android.

With a fresh start I can also start looking into build size and actual frameworks that are needed instead of just blindly installing defaults that I used. This will make me sleep easier at night.

I’d rather have a slimmer Android version than a bloated app or, worst, no app at all.

You may have noticed that the past few weeks have been super quiet on the Gluon front. This has been because of a few reasons, one of them being an influx of freelance work that I have to finish before the holiday… I have not been stressed and deprived of sleep like this for a while. It all seems to come in at once, when you least want it. However, there is another reason… which has taken me a few weeks to think about.

How Gluon is built

Gluon is built with [React Native](https://facebook.github.io/react-native/), which comes from you favourite company that everyone loves (not). React Native basically allows you to write everything in JavaScript using the “React” way, which in turn creates a fully native app. On top, I can probably share 90% of the code across iOS and Android. This, you see, is why I was able to move so quickly with everything. Not to mention the experience of a summer long job creating a big app for a German football club.

This is great and I’m happy I got something out the door that actually works well enough on iOS… and that renders something on Android without much work.

Dropping React Native and going all native

I wrote my first app for iOS just before Swift came out so I learned to write, and read, to some extend Objective-C… then transitioned to Swift as soon as it was announced a few months later. I vowed on that day that I will read the manual from front to back and know Swift like my life depended on it. After all, I always wanted to develop for iOS. It was great. What wasn’t great is that it kept, naturally and un-naturally, evolving at a super fast pace. Every year for a few years I had to update the app so it wouldn’t break or keep at the same big size over time, due to the embedded Swift libraries. The guide book also got bigger.

So 3 years after that I had a good knowledge of Swift but I had to relearn a lot of things. This was a bit too much to keep on doing every year, especially when your day job (at the time) programs in C# and you’re mainly stuck with that and on the side jobs trying to improve your skills in other areas.

However, I think Swift is great! Especially compared to something like JavaScript. Swift isn’t perfect, but it’s a 100,000% times better than JS. In JS everything can be anything and anything can be everything. A null can be a “null” on Android. A ZERO can be false, or actually “0” or a 0… depending how it felt on the day. Yeah sure, I can get around this easily, but you see my point hopefully (“OMG, he’s doing it wrong the n00b!”). Swift on the other hand is just plain type safe. I love that.

Anyway, digressing a bit.

Being stuck with mainly JS frontend frameworks (React.js) and React Native all this year… I think I’m totally over it for anything personal that I’m going to be working on. Things can get overly complex in a matter of weeks. However, I do enjoy using it at a small scale as you can do some really great things with. As they say… “Been there, done that, got the T-Shirt.”

So the main point is that I went down this road, can do it and was able to learn about this “hot” new JS framework of 2018. Not to mention living in the world of what is a 500MB node_modules folder per project… Who actually thought this was a great idea when they woke up one morning? When you freelance and work on several projects… that can become a problem.

Alright, so here is the nitty gritty.

I want to get back into the swing of full and native iOS development using vanilla Swift. This means coding in Xcode, building my interfaces like Apple intended and using their native API’s to do great things. I don’t want to rely on any third-party library. I don’t want to install anything via a POD. I want to know what my code does. I really want to embrace the eco-system that is iOS and also macOS. I don’t want to write another line of JavaScript for main parts of Gluon.

Not only that, I have looked closely at the performance of a React Native app, compared to a well written native app. If you want to drain your battery and spike your CPU, go the RN way for sure. Sure, there are changes coming to RN that will change this, but still… a great app should also be one that is mindful to the user resources. Performance on Android is just horrible for anything beyond basic. This is my personal experience. For sure, there are probably ways to do everything better.

Another contributing factor to my change of heart are these two nuggets from Daring Fireball: [This one](https://daringfireball.net/linked/2018/12/05/react-native-accessibility), and [this article](https://daringfireball.net/2018/12/electron_and_the_decline_of_native_apps)

Third party frameworks for creating apps like this are not first class citizens. They never will be. I had someone email me regarding Android and helping me look at the accessibility on Android. The first article above really speaks for the work that is involved to even get anything that is good enough.

Android

With the above, that also means that the life of the Android app will not see the light of day. The simple reason is… I’m not an Android developer and don’t want to be. Take a hard look at Android Studio and talk to me about developer happiness with a straight face.

Not to mention, we have a general “no Android” policy in this household.

Once Android becomes privacy first with better development tools, I may explore it in future. I don’t use Android day to day, so I have no clue what an Android app should behave like.

I think it’s wise to accept the fact that I don’t want to develop on Android. There are people that embrace iOS and people that embrace Android. In order to truly create something great, you should really stick to what you’re passionate about. Do not think “Meh, this works on both and is good enough”, without actually thinking about it. Or “let’s wrap this web app into an Electron app and be done with it”. No thank you.

So, for the tester on Android - I am truly sorry it has come to this. There are great Android apps out there and I would totally recommend you go with [Dialog](https://play.google.com/store/apps/details?id=com.dialogapp.dialog) for Android. I recently installed it to see how good it is. It’s great and was done by someone that understands, lives and breathes Android.

I don’t want to create a shitty “meh, good enough” app for Android.

At the end of the day, I’m concerned about the user and, of course, developer happiness.

The future

This is no easy task but I have set wheels in motion to start fresh, from zero. The current TestFlight for Gluon expires in 65 days. I may push another one out to keep that clock running a tiny bit longer whilst I work on getting it to the same state that the app is in now, with a few tweaks of course.

Android alpha will still be available until I ship the iOS version. You’re more than welcome to use it, so email me if you want to be on the list. It will, at some stage next year, go away.

I will blog about the process, as I go about re-building it.

For 2019, this will be my long running “code challenge” - re-write and ship.

It’s not going to be your usual attention grabbing app

Many social apps make you come back into the app by sending unnecessary push notification, badge your app icon with millions of red circles and white numbers… they badge your tab bar with icons to say “Oh hey, here is something new that YOU DID NOT READ… OMG STOP EVERYTHING”… or “Oh hey, you have a BILLION unread items waiting above”.

Gluon will not be like this. Gluon will sit there quietly until you open the app, ready for you. Ready for you in the now, the right here, in this moment of time. Not taking your time away from your family or other real social engagement. No FOMO feeling.

Too many times do I see people driving in their car, looking at their phone on some social network of choice, because they probably got a notification. Or teenagers chatting to their friends in front of them, looking at their phones because of some fake and created social thing they are in to at the moment.

Sure, that’s not my problem and sure… it may deter a few people away to another app. I don’t mind, because at the end of the day I know that I created a, hopefully, nice app that works great and has a few happy customers. That is all I want. If this reach is just me, then that’s good for me… if it’s 10 people, then I’ll be happy.

Life is busy. People are busy… busy in the wrong way, out of choice or habit. One reason I don’t use a task manager anymore… because I don’t want to be busy with managing it. Piece of paper for the day works for me for most things I do.

The official Mirco.blog app is great and love the way that notifications are just plain quiet. No sound, no attention grabbing tactics. At first, this was weird but I totally love this little detail.

My aim is this: Have a great working app across the Apple eco system, that is friendly and respects the user, doesn’t interrupt your time and which fully embraces the micro.blog eco-system.

And no, I will not make a [insert a really popular iOS twitter app here] clone.

Gluon build 20181124.2 is coming your way. Fixes issues with seemingly endless images loading in the image modal (1 image ~ 17 images, ha!). Also added experimental swipe to close, so drag that image down and it will close the modal.

And now that I posted a big blog post about Image Modals... I find a bug which basically just loads the same image over and over again. Hot fix in a moment! Will be build (20181124.2).