Intro

I make apps. Small apps, big apps, notes apps, utility apps, social network apps, you name it. I also happen to make a small podcast player called Cosmicast, and this week I updated it to 2.0.

This wasn’t a 2.0 like any other. This was a complete rewrite from the ground up. It was essentially its own new app. I already had a podcast app on the App Store, so it made sense to launch it on top of that one. One of the most prominent questions I kept receiving was whether it was built using SwiftUI. No. It was built using pure Swift, and entirely atop UIKit.

SwiftUI may be great and all, but it’s still too young for me to dabble with, uhh phrasing. I’ve personally been using Swift for the past five years since its launch (also the amount of time I’ve been making apps), and it’s something I’ve grown quite fond of, and dare I say, experienced in. The animations I sprinkle throughout my apps may feel like something easily achieved with SwiftUI, but instead it’s something not-so-easily achieved with Swift. I’ve also made a small developer utility app called Fabula which allows you to craft and play with animations, and a color utility called Aurora which lets you get extensive information about tints from palettes and the real world (just to show how serious I am about animation and design).

You may ask what sets this app apart from the myriad of other podcast apps out there, and I would struggle to come up with a definite answer. It could be the great UI and animations, or it could be its simplicity and ease of use. Maybe it’s even the way it feels like a callback to fonder times when skeuomorphism reigned and the world was a better place. Either way, you have to use it to understand what sets it apart, and the joy it sparks.

Cosmicast Development

Ever since version 1.0, I’ve always wanted my podcast app to tick three specific boxes. I wanted it to be able to play podcasts (duh), discover podcasts without any fuss or complex parameters, and look beautiful whilst doing so. Without the first one, it wouldn’t be a podcast player. But without the last one, it wouldn’t be a podcast player by me.

The new Cosmicast (including the iPhone app, iPad layout, Watch app, and Mac app) was created from scratch in about a week. That may sound ridiculous, but it’s very achievable. I started on Thursday March 26th with an urge to make something that people would enjoy using. After all, that’s what apps should be, right? A little bundle of joy that inspires awe. Otherwise people would just use websites (shudders) or Siri Shortcuts to achieve what they needed to. I would like to say I started by drawing some wireframes or throwing together some dirty mockups in Sketch, but that would be a lie. I’m personally not a fan of planning out an idea as I find that unnecessarily restricts the vision to a very concrete set of steps. Instead, I dive straight in to coding my vision. That way, I have parts of a working app at the end of it. This is not to say that mocking up and planning ideas is bad, it’s just not for me.

The first thing I wanted to create with my new podcast app was a playful skeuomorphic element, and what better place to incorporate this than in the player view. The notion of vinyls on a turntable came to mind almost instantly and I didn’t second guess it at all. In hindsight, I probably should have, as it’s been pointed out to me many times since then that no podcast has ever come in vinyl format. This was coded in a way where tapping the play button spun the vinyl, and tapping pause would stop it rotating, which I enhanced further by increasing the scale of the vinyl too when played, and adding an arm that rotates in when it’s playing. I needed to add a discover section, a library, and a categories/topics section somewhere in the app, and seeing as I had given a lot of emphasis to the player view, it made sense to me to have that as the central view, with all other views revolving around that in some way or form.

I’m not a huge fan of modal presentation views, and tend to use them sparingly. And so, I made the podcast lists accessible in the same view as the player, a button tap (and an animation) away at all times. I also added a gesture to this later on in the week to make it even easier to access and dismiss. I did end up using modal views for accessing podcasts and episodes, as I found that was a different context altogether, and needed a separate visual dissonance. Podcast views had their own little whimsical addition. A vinyl animating out of its sleeve, almost as though it was being opened and slid out. This again tied in to the approach my app was taking with using skeuomorphic elements where applicable. By the end of the first day I had the layout of the app and various moving parts sorted (along with real data being fetched).

Day two began with tidying up the visuals throughout the app to make it look as clean and professional as I could, and posting a tweet about what I had been up to. To my surprise, this ended up getting a lot of interest and traction, suggesting that what I was working on was something people wanted to use, and something I should probably get to finishing soon. This gave me the much-needed motivation to further refine the app and add in more features at the request of my Twitter followers. I also went on to add iPad support, which involved a different layout for landscape to make the most of the space available on larger-screened devcies. Just inflating the app wasn’t an option for me as I knew how annoying it was to use an iPad app that felt like an iPhone app.

All this while, I had submitted a TestFlight build and was waiting for that to be approved (what’s up with TestFlight builds taking longer to review than App Store apps anyways?), which finally got approved on Monday March 30th, and I let it out in the wild for the first time. Scary. But also very rewarding, because the feedback was overwhelmingly positive. This also gave me a chance to find and squash any bugs I had with the app. And in the meantime, I added things like iMessage Stickers, Siri Shortcuts, custom app icons, home screen Quick Actions, and more.

On Wednesday April 1st I added Apple Watch app support, and on Thursday April 2nd I added Mac app support using Catalyst (which I also tweeted about). The Mac app included a toolbar and menubar items, along with slight restructuring and the lack of some areas like Siri Shortcuts and alternative app icons. This was done much quicker than I had anticipated, and it gave me time to let the app rest and marinate for a bit, to see whether any surprise bugs or issues popped up. Alongside this, I started making App Store screenshots (because if I left this to the last day, it would definitely get frustrating). With screenshots, I always try to make them look as clean and generic as I can, which includes setting the time to 9:41, battery levels to max charge, and network status to full bars in the simulator.

xcrun simctl status_bar BOOTED override — time “9:41” — batteryState charged — cellularBars 4 — batteryLevel 100

Also on Thursday April 2nd I submitted the app for review (which comprised of the iOS and macOS variants in a unified app bundle). These went into review in under an hour, and both got rejected in about another hour. Seeing a rejection message is terrifying, as it could be a number of things either wrong with your app or with the metadata in the app submission. This time, it was a metadata rejection, and the reason was odd. For the iOS app, the reviewer requested a video of the app running on a physical watchOS device, and made it clear that it could not be a simulator. Odd. Almost as though they’re aware of some bugs on the simulator that behaves differently to a physical device. And the Mac app got rejected due to screenshots containing podcast artwork for podcasts I hadn’t got explicit permission to use. Fair enough.

I set about recording a video of the app running on the Apple Watch, and I encountered various bugs that I hadn’t come across on the simulator. Huh, I was glad they rejected it now. I rectified these and updated the screenshots with artwork I had permission to use, and then I realised I hadn’t made an app preview video. What better way to show animations and whimsy in an app than through a video? This was pretty quick, and something I have created a template for in iMovie already for many of the previous apps I’ve made. Similar to screenshots, I tend to set the status bar elements looking pretty, and start recording.

xcrun simctl io booted recordVideo clip.mov

The app was submitted again for review on Friday April 3rd, which got approved for the iOS counterpart almost immediately, but the macOS bundle got rejected again. This time for failing to provide read permission in the file manager when attempting to import podcasts, woops. This finally got approved on Monday April 6th (cutting it quite close), and launched on Tuesday April 7th. The app is available as a single unified purchase on the App Store, so you can get the iPhone, iPad, Apple Watch, and Mac app all in one go with no hidden IAP or extra costs.

In the meantime whilst the app was waiting for review and launch, I was busy working on the next update. This includes CarPlay support, chapter markers support, more Siri Shortcuts, more alternative app icons, more iPad keyboard shortcuts, and a variety of other additions and fixes that didn’t make it into the launch version of the app. Adding CarPlay support was entirely new to me, and involved filling out a quick form and sending it off to Apple to request special entitlements that would allow for it to be deployed on the App Store. Getting this entitlement took about two to three days, and the response involved a helpful link to a PDF detailing how to use the CarPlay-specific APIs and frameworks.

There’s a lot more I plan to add with each subsequent update to Cosmicast, and I can’t wait to get it all out there. If you want access to a variety of the images/videos used here and on the App Store, I have a press kit available. You may also be asking why I chose to use a turntable vinyl metaphor for a podcast app, and to that I have no valid response apart from me wanting to try new things and play around with what a podcast app should be. I also plan to include music in this app in the future. But more importantly, Hello Internet has a vinyl episode so it’s only fitting.

Outro

If you’ve got this far through this wall of text, thank you for taking the time to read about my journey. If you enjoy using Cosmicast, please let me know and leave a review on the App Store. If you don’t enjoy using the app, please let me know so I can improve it through an update. I’m a solo independent developer who loves all things Apple. Creating apps like this in my spare time allows me to pour my creativity into something I can be proud of. Seeing support for the same apps inspires and motivates me to go further and do more.

I’m very grateful for the support I receive on Twitter and elsewhere from people I admire and look up to. These people create better products than I do, yet hype up my products like their own. A lot of what I do couldn’t be done without the insight they provide, the help they give, and the guidance they impart. Building an iOS app is made better by the community that consumes it, and I’m thankful for the great community I’ve started to become a part of.

Please let me know if you have any questions or feedback about my random ramblings through Twitter @JPEGuin.

Bright Beginnings

Last week on the 29th of January I launched Aurora (my new colour-picker and dictionary app for iOS and macOS). It was born out of a need for a tool that let me quickly and easily get information about colours and pick them from images as well as from the camera. Tools like these were abundant on the web, but not on iOS.

On the 29th of December 2019 (exactly a month before launch) I set out to make something that would be a useful tool for myself first and foremost, something that would enable me to speed up my workflow and get quick access to colour details directly from my phone and other mobile devices (yes I spell it ‘colour’ as I’m from the UK, and yes I also spell it ‘color’ everywhere else to appeal to the wider audience). At this stage, I had no name for my app, no icon thought out, no clear vision as to what it will end up looking like, and definitely no indication of whether anyone would even want to use it. All I had was an idea — I wanted a colour-based app that would give me information about colours typed in.

Random Ramblings

I’m not one to create plans and think an idea through to the end, as I often find that plans are limiting and create false constraints. Ideas strike anywhere at any time, and limiting it to what you thought of at one point in time isn’t doing you any favours. An iterative approach with flexible paths leads to the best version of whatever it is you’ve set out to do, with the only downside being your imagination. This post may itself sound like I set out to make an app in a month, which I promise I did not. Coincidence is seldom useful, but this one served its purpose in the form of a great title. The lack of a defined playbook and rigid plans led to an app that was vastly different from what I envisioned in my head on day one, and one that was much improved upon by feedback from users too.

I don’t wireframe or mockup designs — I just start coding. It saves time and it allows me to change things directly and see them on my devices in one go. To say I ‘design’ my apps would be a stretch as I merely code and develop what I see in my head. I’m a very visual person but don’t use visual cues on paper to imagine the layout and positioning of elements (I never use Storyboards). I tend to know exactly how much 2px will move the item via code. Things like that come from experience above all else (I have been doing indie iOS app development for 5 years now). I’m far from an expert, but I’ve gained enough experience I need through the years in the areas that matter to me. I’d like to gain the same amount of experience in code cleanliness and code patterns over the next 5 years (I’m far from writing code as pretty as my UI).

Aurora App

My first iteration retained various aspects of the finished product — there was a tab bar, and a central screen with colour input and wave-like animations, and the ability to see various details. This was the core of the app, something I deemed essential in its purpose and selling point. I hadn’t thought about what the other tabs would display, and what other functionality the app would contain, that would come later. For now, it was all about getting something down in the form of an interactive app that can be used on a physical device. This is my approach with all of my apps — to always have something that can be shown off to people around me and on Twitter in the form of a screenshot or screen recording no matter what stage the app is in, whilst still looking complete enough from the small glimpse provided. I didn’t know much about colour and all of its aspects, so I did some research into what a HEX value is comprised of, what RGB and CMYK’s differences are, and how the different values are useful to different users. Whilst I learnt a lot, this wasn’t essential to the app’s functionality and codebase.

What was essential was finding an API that would allow me to get relevant details, especially names for colours (as I could manually fetch the rest of the details, but I wasn’t planning on assigning a different name to every conceivable colour visible to the human eye). I found an API that provided what I needed, and quickly implemented it into the app and had something working on day one. I went on to replace this API with a better one as the days progressed, but it achieved more or less the same desired outcome.

This screen had the notion of whimsy built into it from the get-go, with the added bonus of brightness and saturation sliders stylised as physical taps (giving the impression that the paint is filling up). I always try to add something into my apps that creates a moment of awe and wonder; something that sparks joy, even if it is for a brief moment. I personally believe that this makes the app memorable and stand out amongst its competition, and gives the user a small talking point and need to share with others. And it’s just fun to play with; something we can all do with a bit more of. There were various guidelines I gave myself in terms of what the app should look and feel like, adding to its sense of consistency and familiarity. It had to support new Apple technologies such as dark mode and context menus (this made it feel the part on iOS 13, and didn’t cause it to feel dated from launch), it had to use system fonts and system symbols (SF Symbols), it needed to be playful, and it had to provide haptics for a sense of depth and affirmation of interactions. A lot of these self-imposed requirements were to keep the app current and increase its chances of being appreciated as an app that had given thought to its attention to detail, but one of my requirements was a little different — playfulness. This came about through its whimsy and lowercased fonts. Most values in the app (HEX, RGB, CMYK) are often portrayed across the web in capitals, but I personally found this to be too harsh and daunting. This conscious decision to replace conventional norms with improved UI is something that comes down to a case-by-case basis, and the benefits have to be weighed against the negatives. In this case, I didn’t see the need to retain capitals.

At this point I’d like to mention that I didn’t work on this app everyday, and certainly not every hour of the day. I spent maybe two hours per day working on it, more on weekends, and less on some days. This leads to me having very little to talk about in terms of how my app progressed linearly throughout the month. Although, I can provide insight into what changes happened to the app within the month regardless. I quickly realised that the app needed a way to store and save colours I had previously searched for, and so I added this functionality to one of the tabs. Lists are boring, but visual implementations of the same list are not; and so I chose to use a CollectionView to create a grid of colours that almost looks like a physical watercolour palette. This colour grid alone served no purpose, but tied with the ability to tap the colours to view their details, it started becoming much more useful. The colour details modal started off displaying the colour name, the HEX value, and related values such as RGB, CMYK, and HSV. Just enough to be useful, but it felt really empty and void of character. The lack of a beautiful UI in this modal led me to try add something that would deter it from becoming a boring list, and so I had the idea of related colour palettes. These palettes were styled similarly to the watercolour-styled palette of stored colours for the sake of consistency and familiarity across the app, but were scrollable horizontally to keep them compact and traversable in ways that didn’t distract the user from the other content that was available. The idea of adding shareable code snippets came much later, and the use of related Pantone and Crayola palettes came in the last day of development. These features were arguably this area’s best features, but weren’t initially intended to be included at all — which again shows the importance of being flexible with implementing what an app should be capable of doing.

I still had one tab left to figure out what to do with, and I was struggling to find something that would be useful for people working with colour. And then it hit me. People like to know the colour of things, be it from images or real world objects. So I started work on a live colour picker with a toggle to allow picking colours from images that the suer had passed in themselves. This was arguably the most difficult aspect of the app, and it took some time to get right. The picker was made draggable, and the ability to pause the live stream was added as enhancements that may have been useful for users. Near the end of development, I also had the idea of adding a colour-replace feature, which elevated the app to a greater level. I’d also like to add that I didn’t use any third-party libraries for this, wanting to do this all myself and keep dependencies to a minimum. This also led to the entire app being a small 1.5 MB on the App Store (and an even smaller 0.5 MB on the Mac App Store).

The Watch app was something I wanted from the beginning, and it was something I got set up in a few hours. It has the ability to view the saved colour palette from the main app, and view individual colour details. Anything more would probably have been overkill, but I’m intending to play around with expanding possibilities for future app updates. The Today Extension widget was essentially the same feature-set as the Watch app, and something that would allow users to quickly get palette information from anywhere on their device. Furthermore, a ‘sharing’ feature was something I wanted the app to include before launch; something that would allow users to share an image representation of the colour to others and to their social media directly from within the app (in hopes of it promoting the app itself). This was added near the end of development, and shares an image of the colour with its details, and contains a small watermark underneath.

Lazy Launch

Halfway through the app’s development, I opened up public TestFlight betas to get user feedback and see whether there were areas I could improve upon or bugs that I hadn’t come across from my own personal testing. Public beta testing is incredibly useful and something I’d encourage everyone to partake in if possible. It led to me discovering various small bugs that I wouldn’t have found out by myself — one of them being an issue where the live camera stream on the iPad would be rotated 90 degrees (something I wouldn’t have discovered myself as I didn’t have a USB C cable at the time to test on my iPad, and there’s no camera functionality on the Xcode simulator, so had to rely on the feedback from helpful users). The new screenshot feedback feature on iOS 13 is also immensely useful as you can see exactly where the user was facing issues. I understand that they could just email me instead, but this is convenient for both testers as well as myself. Only downside is that there’s no way to get notifications for these so I’d only see them if I checked manually (there were many cases where I’d already pushed out a new build and then seen some important feedback — sometimes I’d already addressed their concerns without having seen them, which always felt like a win).

I didn’t have a set goal or date for when I wanted to launch the app (some apps are topical and make sense around holidays or periods that reflect what the app does, but there didn’t seem to be anything like that for Aurora), but I did want to get it out there as soon as possible. Once I had the app in a state I was happy with, I set about creating the App Store metadata and screenshots. I use Sketch for creating assets, and did so again for Aurora, with a different set for each type of device that the app supported. Whilst creating these, I realised I’d forgotten to make something — the Mac app. The Mac app was something I’d wanted to have as part of the launch from day one, more so because of how Catalyst now makes it much easier to port UIKit apps over. It’s just a checkbox, right? Well, yes and no. It really is as simple as checking an option in Xcode to enable macOS support and set the ball rolling, but how far you want to take it is entirely up to you. I ran it in the simulator after checking the box and it was fine. Everything I expected to be there was there, and everything I thought would cause an issue did indeed cause an issue. First thing first, I removed support for the live camera picker as that wouldn’t be usable on a Mac. I then went on to removing the menu bar options (and adding my own custom ones), this is something most people don’t tell you — irrelevant menu bar items could get your app rejected, especially having a help section that leads nowhere. I was more or less happy with these changes and then submitted this to the App Store, but quickly changed my mind after realising that it still very much looked like something that belongs on a touch screen device. And so I set about switching out the tab bar in favour of a toolbar, which looked much better and fit in to what I’d imagine a Mac app to look like.

I chose to go down the preorder route with the Aurora iOS and macOS apps, not for any particular reason, but rather because I wanted to give myself time to push last minute emergency updates if I needed to before launch. This was intended to be a week, but I ended up releasing a few days earlier because the anticipation was killing me. I also wanted to give some time to start promoting my app to the press. I’m not sure whether anything worked, but I gave it a shot either way — I emailed and messaged various tech publications I was a fan of, and tweeted about the app in hopes that it would be picked up by journalists and tech reviewers. I also posted on ProductHunt and Reddit after launch in hopes of increasing eyes on my product. Whilst I can’t comment on whether anything I did made any impact, it did get picked up by 9to5mac, AppAdvice, and iDownloadBlog; and that’s led to more downloads than I would’ve had without them. Aurora is a very niche product, and it’s more evident with the knowledge that after a week out in the wild it has gained roughly 300 downloads.

Before launch, I was under the impression that my app Aurora was one of the only ones in its category. Immediately after launch, I came across two new apps that did some aspects of what my app did in different regards to different extents. The part that surprised me most was how eerily coincidental it was that all of these apps came about around the same time; almost as though the universe has its own way of repopulating thoughts and ideas to strike a balance. It’s most likely the result of the Baader-Meinhof phenomenon, where your brain tend to see something everywhere after being excited about that particular thing. Spooky.

End Extras

The name Aurora was born out of the beautifully magical Aurora Borealis with its array of colours that draw you in and cause you to stare in awe. I added localisation for the different English-speaking countries primarily to differentiate between ‘colour’ and ‘color’, and I plan to expand to other countries in future app updates. The app icon was initially different, but I deemed it far too dull and subtle for an app focusing on colour. The current app icon is simple enough to recognise, bright enough to catch the eye, and distinct enough to be recognisable from a distance and amongst a screen full of other app icons. I often try to consider these things when designing my apps — does it look nice, does it look professional, does it look Apple-esque, does it look the part on the user’s device, does it look different enough to catch the user’s eye, does it feel like an iOS app, does it follow the Human Interface Guidelines, does it look award-worthy, does it contain new Apple technologies, does it push the limits of what an app can do, does it feel unique, does it go beyond the norm, does it spark joy, does it turn heads? If the answer to most of these questions is ‘yes’, I release it into the wild and sit back anxiously awaiting feedback.

I’m very grateful for the support I receive on Twitter and elsewhere from people I admire and look up to. These people create better products than I do, yet hype up my products like their own. A lot of what I do couldn’t be done without the insight they provide, the help they give, and the guidance they impart. Building an iOS app is made better by the community that consumes it, and I’m thankful for the great community I’ve started to become a part of.

Please let me know if you have any questions or feedback about my random ramblings through Twitter @JPEGuin. If you enjoy using Aurora, please consider leaving a positive review on the App Store… Who’s excited for WWDC this year?