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.