SwiftUI makes customising your app to how you like too easy that sometimes it feels like you might be implementing views the wrong way.
With the demise of Twitter, and the boom in all the Mastodon apps, for the first time in a long time I have been bulk downloading new apps to test.
Each one out there is great, and the ones I tested were Wooly (currently in Test Flight), Ice Cubes, Ivory, and Mastoot. But one thing I noticed with most of the clients that I was trialling was the level of customisation in the tab bar.
At first I thought, these are built in UIKit, but was sure that it is possible to build it in SwiftUI. I have no evidence on which framework each of the above apps are written in, but I did go down a long journey in the process of creating a custom tab bar.
Some things I wanted to achieve were:
- reorderable by the user
- animation on tapping
- haptic feedback
- audio feedback
Recreating the SwiftUI TabView
My first method was going through the process of recreating the in-built TabView provided by Apple.
The thought was if I can simply extend the existing functionality then I've pretty much achieve my intentions.
With most things SwiftUI, this topic has been covered, and what Nick does really well is keeping the code functionality as close to the original functionality as possible.
This version was great as it had the ability to customise like I wanted, and it kept the same TabView closure format as the original version.
I should have stopped looking here.
Swipe-able TabView
In my research for creating a new Tab View, I also came across turning the standard tabbed bar version into the paging swipe version.
In one of the tutorials, it explained how to have both visible "tabs", as well as being able to swipe across to the other views.
I got hooked on to the idea of how cool it would be to have all my views, let the user to swipe left or right. Everything was accessible from a gesture.
I mean at this point the first version, and this swipe-able version both let me customise the tab item, adding haptics or audio, and animations on press down.
But I went too far, I tied to combine them - swiping views and native feeling tab bar.
Icarus and the sun
Trying to combine the two got be burnt really quickly.
I had the most hacked together piece of code. It was 99% complete, and it was over-engineered. Why did I need both? I was trying to create a feature set even before I had a user base or an app.
I almost scrapped the whole thing and went back to the Apple native TabView. No animations, no haptics, no audio - nothing.
Lessons
What am I getting at here - and what's the point of these ramblings?
This is a reminder to future me. Do not try and make something so ultra polished even before you know what works or what needs work.
At the end of the day it is only a Tab View.
Yes, it is the main way of navigation in the app but it is all it needs to be right now.
Make something functional, and once it is at that stage, then you can iterate.
It might come natural to people who have done this for many years, but in the beginning just get apps made.
Maybe once I'm happy with my navigation, I'll post it here and link to a project - at the moment I'm simply pairing it back to functional but realistic.