I think I mentioned it briefly, but Focuses is built mostly with
SwiftUI. Overall, I'm very impressed with SwiftUI. I don't think I
would've been able to build the first version of Focuses as quickly as
I did had I not used SwiftUI.
Focuses is my first "real" iOS app. My first app,
Send To Nowhere, is a simple app using UIKit, Swift, and no storyboard. I'm still a
novice when it comes to the iOS ecosystem. I'm a full-time web
developer by day, so using SwiftUI felt familiar in ways. However, the
declarative nature of it still feels quite foreign from time to time.
SwiftUI: The Good
I was worried that SwiftUI wasn't going to be mature enough to
complete my app. I was surprised at how capable it currently
is—despite it's many shortcomings—and I'm very excited to see it
develop. It's not perfect, but I was able to use it for about 95% of
my views. Even in the short time I have been building Focuses, I've
seen great bug fixes and improvements come to SwiftUI. I'm very
optimistic for it's future.
SwiftUI made some things in Focuses a breeze to implement. Take the
animation when filling up the circle. That whole view, including the
animation, took me about 10 minutes to make. Again, I'm not a UIKit
expert, but I have no idea where to start if I had to make that same
view without using SwiftUI.
Animation of score indicator filling up
Creating complex layouts like the calendar was relatively straight
forward as well. I think my first implementation had too many nested
views, which were being rendered too often, so it took a long time to
load. But it was easy to go from idea to implementation quickly. I was
able to iterate and make a much more performant version fairly
quickly.
Sreenshot of Focuses calendar with boxes around elements
I also like how easy it is to use CoreData with SwiftUI. There were
times that things weren't updating when I thought they should've, but
I found ways around it. This was my first time using CoreData, so for
all I know, I could be doing everything wrong and that's the source of
my problems. Hopefully not though.
The main issue with CoreData and SwiftUI, in my opinion, is previews.
I could not find a way to adequately seed that database for previews.
So for much of the project, I did not use previews. Maybe I need to
take another look at this.
SwiftUI: The Bad
SwiftUI is great at hiding complexity and implementation details, like
when using @FetchRequest. However, once you want to do
something that is more complex, like pass in params to your fetch
request, things can get messy.
Here's a couple things I needed to use UIKit for:
Text fields that I wanted to become the first responder (i.e.,
receive focus when the view appears and show the keyboard).
UITextView. There doesn't appear to be a SwiftUI
equivalent of this. I needed a multi-line text input for notes. I
also wanted an input accessory view, and I believe this can still
only be done using UIKit.
I wanted to set the scroll position of the calendar view so you
would start at the bottom. The only way I could find to do this is
by using a UITableView. I was still able to use my
SwiftUI view for the cells.
There's also some things that just don't make a lot of sense. Action
sheets do not work on iPad. You have to use a
work around. iPad support in general seems kinda weak. I’ve found it tough to
make layouts for iPad, part of the reason the first version of Focuses
doesn’t have great iPad support. I need to spend more time figuring it
out.
I also had a lot of trouble embedding forms inside other
views, like on the privacy and about views. My solution is hacky and
doesn't respond well to changing the system font size, but it works
for now. Essentially, I have to give the form a set height based on my
best guess using the font size. Additionally, I have to use
.fixedSize(horizontal: false, vertical: true) on all the
text so it would wrap properly.
I also wish there was a way to customize the navigation bar. As far as
I can tell, you're stuck with it's color and font.
I'm hoping all these things will be addressed in iOS 14, or possibly
even point updates of iOS 13.
Conclusion
The best resource I've found for SwiftUI is
Hacking with Swift. The examples are fantastic.
If I were starting a new app today, I think I would still start with
SwiftUI. I feel like I'm faster when I use it, and it's pretty simple
to use a UIKit view if you need to. I think I've only scratched the
surface of what SwiftUI is capable of. I need to delve deeper into
animations and transitions.
I'm excited for the future of SwiftUI. I feel like it allows me to
create things I would've dreaded to try a year ago.
If you're curious about how I did anything in Focuses, let me know on
Twitter, or use the
contact form. I can dig into the nitty-gritty specifics.
Here are a few numbers related to making Focuses that may or may not
be interesting.
130 hours
This is the first project I have time tracked. The first commit for
Focuses was on December 13, 2019. About 13 weeks later I submitted it
for review. So that's about 10 hours a week. Some weeks were much less
and some were much more. This also doesn't include times when I was
thinking about the app when I couldn't sleep or showering and stuff
like that. A lot of the work on Focuses was done early in the morning
before I started work for my full-time job. 130 hours seems like a lot
to me, but it's about 3 weeks of full time work.
147 tasks complete
I'm using Things to keep track of everything I'm working on for this
app. This probably isn't that useful of a number since my
tasks ranged from "iPad" to "Fix accent color on focus
edit sheet". But 147 sounds kind of impressive.
183 commits
A commit is every time I make a change to the code and save it to
version control. Only about a dozen of these were of the
"Uncomment code I commented out" variety. My build number is
based on the number of commits on the master branch. Again, this
number doesn't mean a whole lot because some commits were changing a
single color and some were adding multiple views and data models at
the same time.
19 minutes spent in "In Review"
This surprised me. I submitted it for review about 7 am on March 9.
About 6 hours later it moved from "Waiting for Review" to
"In Review". Then about 19 minutes later it moved into
"Pending Developer Release".
Let me know if there are any other numbers you're curious about on
Twitter, or use the
contact form.
Focuses is my take on goal and habit tracking. It is inspired by Myke
Hurley's daily themes and Marshall Goldsmith's daily active questions.
The idea is to have a simple and flexible system for scoring yourself
on how you do towards your goals each day. There are 3 options, an
empty circle, and half-filled circle, and a filled circle. What these
mean is up to you.
When SwiftUI was announced at WWDC 2019, I began thinking of projects
I could try it out on. An idea for a daily questions app kept coming
back to me. It would be an app that asked you the questions you wanted
each day. Stuff like "How did you do towards eating healthy
today?" You would respond with some like "Bad" or
"Good". I started a version of this app, but abandoned it. I
didn't like that approach. It felt too constrained.
While listening to
Cortex, I heard Myke talking about his system of rating himself on a scale
of 0, 1, or 2. Those scores would add up to a daily score. I really
liked that approach. It felt flexible and easy to track. I tried it on
paper, but it didn't stick. So with the New Year fast approaching, I
thought why not try to make a simple app to do it for me? I'm a novice
iOS developer at best, so what I thought would be simple was not so
simple for me. But after about 3 months of slow and steady work, I'm
excited to release the first version of Focuses!
I made the app for myself. I use it everyday. Tracking my effort
towards my goals has had a tangible effect on my life. It's helped me
and I hope it can help others.
For about the last year and a half, my daughter and I have made a
podcast. My daughter is currently a toddler. It's not always easy to
produce a podcast with a toddler, but I have found the end product to
be priceless.
Disclaimer: Because every child is different, this is
going to be less of a how to and more of a "my experience with
podcasting with a toddler."
Motivation
Toddler's are not always the easiest to work with. So why would I
bring it upon myself to try to make a podcast with one?
Like many of my cohorts in the millennial generation, I’m really into
podcasts. Like many podcasts listeners, I’ve thought “I should make a
podcast.” Should might be a stretch. But I definitely
could record audio and post it on the internet.
A couple buddies and I tried starting a podcast called
Average of Averages. Being the tech nerd I am, I loved doing all the technical stuff of
a podcast—recording, making a website, generating a feed, etc.—but I
had trouble figuring out what could make out show different and
engaging. Three white guys talking about nothing? How original. We
never did figure out our niche. Finding time for three people to
record also wasn’t easy. It fizzled out after two episodes.
I still wanted to make a podcast though.
Around this time, my daughter started putting multiple words together
in cute little 18-month old sentences. I’m terrible at writing a
journal. I’m also terrified that I’ll forget all the adorable things
my daughter says. Then it hit me! Here’s a tiny human being, in my own
house, whose schedule I have small amount of control over (more on
this later), and I want some way to record her so I can
remember how cute and little she was. There’s the podcast.
The Lily & Sam Show
was born.
Making the Podcast
After about a year and a half and a couple dozen episodes, I feel like
we're finally at a place where recording and editing is a smooth
process. It's taken a lot of trial and error to get to this point
though.
Starting with One Microphone
We started recording with a single microphone, the
Audio-Technica ATR2100-USB. I chose this microphone because it was recommended both by
Jason Snell
and
Marco Arment
(#4 on Marco's mega review). It’s a great USB mic. My daughter would
sit in my lap and I’d move the mic up and down depending on who was
talking. I quickly realized this was not going to be a great long term
solution. She kept wanting to turn around and look at me and moving
the mic between us often missed what she or I would say. Not great.
Upgrading to Two Microphones
I later purchased a second mic, the
Pyle PDMIC58, a cheap XLR mic also recommended by Marco Arment (#5 on Marco's
mega review). Since this was XLR only, I needed an USB audio
interface.
I was able to borrow a
Zoom H6
from a coworker. I was considering buying one because it would double
as a recorder and an interface. I thought we might have an easier time
recording if I could follow her around and record her in a less
controlled environment. My microphones weren’t suited for that at all.
So we tried the Zoom H6 as an audio interface. Turns out she loved
having her own chair and microphone.
So I knew that was the direction we needed to head. My wife bought
surprised me with a
Behringer UMC404HD
audio interface after I had to return the Zoom H6 to my friend. The
Behringer was the most affordable decent audio interface that had more
than 2 XLR inputs I could find. (I wanted to be able to have at least
3 inputs because my wife occasionally joins us on the podcast.)
I don’t know if you know this about toddlers or not, but they don’t
stop moving. The problem with my daughter sitting in her own chair and
having her own microphone, is she kept moving and touching the mic!
So. Much. Noise. My daughter also liked switching seats with me for a
while. That made editing a pain.
I also got a couple heavy mic stands to set on my desk (these ones). This lets us sit on opposite ends of the desk and face each other.
In addition to being able to put the mics in the right place for both
of us, this reduces the amount of noise bleed there is.
Editing
I edit in GarageBand. I don't love it, but it's free! I've gotten
faster at editing over the months, but it's still a chore.
If you've listened to any of our episodes you know they are short,
like 2–3 minutes. In order to get 2–3 of content, we now typically
record for about 10+ minutes. At the beginning it sometimes took 20+
minutes to get 2 minutes of material. Most editing is cutting out the
parts where it's quiet, she's running off to play with her LEGOs, or
she is being too grumpy. Occasionally I move stuff around to make the
conversation more coherent. It used to take me about an hour to cut 17
minutes of recordings down to 2 minutes. Now I can edit an episode in
about 20 minutes. With 2 mics you get 2 tracks, which makes it easier
to see who's talking where and what can be cut out. I always listen
through once or twice with my eyes closed to make sure it all sounds
decently coherent.
I tried so hard at the beginning to remove all of my daughter's mic
bumps and the noise of her moving in her chair. Eventually I kinda
gave up on that mission. I began to see it as the charm of recording
with a podcast; hearing how lively she is while we record. I
personally think it gives the podcast a bit of character.
One of the hardest parts of editing has been adjusting levels. Because
my daughter moves around so much, sometimes she's too quiet and
sometimes she's too loud. So I have to go through and a bunch of
volume automation points all over to help it sound a bit better.
Screenshot of audio levels in GarageBand
As she has gotten older and her language skills have improved, the
editing process as gotten easier and easier. So the future is bright.
The Website
I will write more about the technical aspects of the website in
another post, but
lilyandsam.show
pulls in data from my custom CMS at
verygood.fm
and generates the RSS feed. It's built with NuxtJS and is hosted on
Netlify. Netlify made it simple to add a form for people to ask
questions for the show. Those questions are emailed to me.
The Future
We're now recording the podcast about every other week, sometimes once
a month. I love having these recordings. I love when my daughter runs
up to me and asks if we can record the podcast. I love seeing her grin
when she listens back to it.
Sometimes it's real tough to make. My daughter gets grumpy and hungry
and doesn't want to record. Or she'll say she wants to record just get
into my office and play. But on average, I'd say it's worth it.
I'll keep making it as long as she wants to.
A Message From My Daughter
My daughter wanted to help me type this. So the following is typed by
her:
I've been working full-time as a software developer for almost 2 years
now. I’ve learned a lot. I’ve messed a bunch of stuff up too. The
question I’ve been struggling with is
how do I know I’m actually becoming a better
developer?
Over the last couple of years, I feel like I'm becoming a better
developer. But is feeling better enough?
What makes a good developer, IMO?
I haven't worked with or known a ton of developers, but I've
worked with some great ones. Besides the actual code a developer
produces, there is lots that makes a developer great. There is lots
that make a developer great, but here are a few things that I think
make a developer (and people in general) great:
They are approachable. They always have time to help the junior dev
like me and give helpful feedback.
They know how to find answers. Because of this, they seem to have a
super-human ability to know everything.
They volunteer to work on the hard stuff. This leads to them
learning more because they stretch themselves.
They admit when they don't know something.
They are not afraid to admit they were wrong.
Unfortunately, all these things are hard to measure. I think most
people can agree that the easy things to measure (number of lines
written, number of tickets closed, etc.) have little bearing on
whether a developer is great. So that's where I get stuck. I want to
get better, I know what I think a good developer looks like, but how
do I know I am better than I was a week, a month, a year ago?
Can getting better be measured?
I like numbers. They are easy to compare. But how do I compare
something like being approachable? I could maybe find a number to
represent it, like number of questions I get a day. I could ask people
to give me a rating on how approachable they think I am, but I'm
guessing the people who like me would rate me highly and the people
who don't would rate me poorly, and that it wouldn't change much over
time.
Let's assume I do find a number or a couple numbers to represent
approachability. Over time, I think I would subconsciously, or maybe
even consciously, find a way to game that number. I'd want to chase
that good feeling that comes from seeing a number improve. My point
is, numbers probably won't work very well. Are all metrics bad? No.
Are most? Maybe. It's hard to find the useful metrics. But they do
exist, I think. But I also know from personal experience that it is
incredibly easy to focus too much on the number and not on the end
result the number is supposed to measure.
So, is feeling better enough?
I'm now thinking yes, just feeling like you're a better developer is
probably enough.
The hosts of one of my favorite podcasts,
Cortex, talk about yearly themes. Instead of making yearly goals or
resolutions, they have a theme. Whenever a decision or opportunity
comes up, you can just look at your theme determine if the decision is
on or off theme. I think a similar tactic can be taken with becoming a
better developer. Instead of creating specific goals or measuring
(pointless) metrics, just keep what you think makes a developer great
in mind, and when situations arise, just ask, "How would a great
developer act in this situation?". Sounds cheesy, I know. But
that's the best I can come up with right now. It's not just wanting to
be a better developer that makes someone better. It is knowing what
you want to be like and acting more and more like that until you
become that.
If you have any ideas or thoughts, let me know. I’d appreciate it.
This is all still forming in my mind. What do you think makes a
developer great? How do you know that you're getting better?