Read the transcript
Jeroen Leenarts: Hi, and welcome
to the 76th episode of my
podcast. My name is John
Lennon's and I've been
developing software for over 20
years developing iOS app for
over 10 years. And I'm running
that skullcaps for over nine
years. If an iOS app developer,
you should listen to my podcast
because we'll keep you updated
on interesting articles,
conferences and events you might
not have heard about. In this
episode, I'm going to talk about
exporting data from unified
logging system in Swift
transitions in Swift UI, unit
testing and UI testing in Swift,
the hidden cost of your
dependencies, how to create get
up action to upload D Sims, and
swift UI performance tips. So
let's get started. So it's
already Tuesday. So normally, I
released my episodes on Mondays.
But it's been an interesting
weekend, I had like two Easter
weekend. So I've been off from
Friday till Monday, and I
completely disconnected of
everything. So that also meant
that I couldn't record my
episodes on Monday. So recording
it right now been very busy
today. So I'm going to do a
quick recording, and dive into
the news articles of this week's
right away, I will update you
more on things that are
happening in my work life and
private life next week. So this
week, I will just make do with
some articles that I think you
should be aware of. Also, make
sure to check back my previous
episodes for some tips on
conferences you should attend.
So definitely check that one
out. It's in the show notes. So
easy to find. So just let's get
started and dive in with the
first article. First article is
by Facebook Majeed. So that's a
follow up article of his
previous article on the unified
logging system in Swift. And
this week, he writes a nice
follow up article that shows you
how you can export data from the
unified logging system in Swift.
So it's a bit of user interface
that you can put in your app to
make sure that you can actually
easily capture the logging from
the unified logging system
without much hassle by an end
user. So you can capture data
from the unified logging system
by doing some sort of a Vulcan
death grip on your device and
then exporting it somewhere deep
from within Settings. But with
this bit, that magic suggests,
you can facilitate this process
to your users much easier and
much more convenient. Thus,
allowing your users to much
easier, catch you some logging
if they run into issues with
your app. So definitely check it
out. If you use ours lock in
your code, make sure to look at
this article, because there's
really good tips in there. The
next article is by objective
c.dl transitions in Swift UI. So
it's, it's an article based on
their findings from their swift
UI workshop, because they
noticed quite often that very
few people seem to know about
transitions in Swift UI, even
though they're not very
complicated, and very, very
useful. transitions happen when
a view is removed from the View
Tree or added to the View Tree.
However, if you've done swift
UI, you will have noticed that
there is no actual way to add
views to the View Tree. There's
no add sub view like yet you
could write. Instead, you can
add and remove views through the
combination of state change and
using an if statement or a
switch for each. In other words,
fuse somehow added and removed
for us automatically gets
transitions fired only once. So
it's an article about
transitions in Swift UI, and how
you can deal with them and make
sure that they behave and are
present in your app in a way
that you want them to happen.
Definitely check this one out,
because it's another one of
those really deep articles
because I have that as a lot of
explanation and helpful. Few
hierarchy images that will allow
you to better understand what he
is talking about in his
descriptions. Next article is by
a new blogger, at least someone
that I don't know yet, let's
call her colleague, hope I said
that correctly, unit testing and
UI testing and swift. His
article covers unit testing and
UI testing, which together play
an important role not only in
proving that code is correct at
the unit level, but also in
demonstrating that the
application meets user
requirements. While unit test
seeks to create rapid and
regular feedback loops for
developers to gain confidence in
correctness of the code. UI
testing validates the
application as a whole from an
end users perspective to ensure
that final product performs as
expected by users. In his
article he cover explains what
unit testing and UI testing is.
And he also provide some case
studies on how you can actually
work with these two types of
testing in Xcode and how you can
get familiar with this if you're
not yet familiar with this
concept of automatic testing to
begin with. So, good reminder if
you are working with unit
testing and UI testing and the
definite must rate if you are
not yet familiar with these
concepts. Then there's the
fourth article called The hidden
cost of your dependencies.
It's by a JSON Sarita, and
dependencies in your projects
have hidden possible unthought
of, or ignored costs when adding
dependency managers tools like
Swift package manager and node
package manager, make adding
third party libraries almost too
easy. With a few clicks, you can
import 1000s of lines of code
into your project and shipped to
users. Sounds great, right? You
got the task done. But at what
cost? Did you think of the main
say, the maintainability of the
code impact to your career
growth, security implications,
the complexity of what you just
brought in? Or how about
transitive dependencies, because
a dependency can have their own
dependencies, and those get
brought along with your
dependency, as well. So
especially with no packages,
those can be like quite a lot of
packages that are underneath
just one single import. So using
a dependency is not always bad,
but you should be intentional
about it. And when you want to
use it, and what the trade offs
are. So in this article, Jason
goes over the hidden costs of
dependencies. So that's
complexity versions, ripple
effects of updating
dependencies, build times that
new code is your support. So any
dependencies code is something
that you need to make sure that
it works in your context. And
it's, it's a good overview, if
you are working with third party
dependencies, and you have to
make your assessments on whether
or not you should actually work
with this third party
dependency. So at stream, we
also tried to make sure that we
hit all the checkboxes to make
sure that stream is a third
party dependency isn't bad for
your codebase. And we, we put a
lot of effort in making sure
that everything works that this
is supposed to end that the
impact of this dependency is as
little as possible on the rest
of your codebase. So lots of
interesting bits in this
article. And I fully aligned
with what Jason Sarita says,
because I'm also one of these
developers, that always thinks
that fewer dependencies is often
always, well, not often always,
but most of the time is better
than, than having more
dependencies. The fifth article
is by some wise how to create a
GitHub actually to upload decent
GitHub actions or jobs that you
can run on GitHub machines.
Sounds simple. When you build an
iOS code base on GitHub actions,
you also need some way to get
these hymns. That's the debug
symbols of your, of your
compiled binary somewhere. So
probably, you want to upload it
to some sort of a crash
analytics server, or he wants to
have it locally so that once
crash logs come in, you can at
least a symbolic aid and that
you can understand what the
crash was about right? So in
this article, Sam goes over the
details of what you need to do
to get these these sims are
working. So firstly, create a
Git workflow, then he defines
job within a workflow, then you
need to get some interaction go
with the app store API is using
Fastlane. And then you're off to
the races. The reason that you
need the app store API details
is that if you use bitcode in
your applications, binaries, so
if you have that enabled in
Xcode, you need to make sure
that you get the decent from the
app store API, because those are
actually correct for the finally
deployed binaries of your
application. Because if you use
the decent starter generated
locally, and you have bitcode
enabled, then those do not match
up with what the end user is
actually running on their
device. Then the final article
is by my colleague, Martin
Petroski, he put an article
called swift web performance
tips on his own personal blog.
And it's a really nice overview
of what it takes to make sure
that swift UI user interface
works all the time without any
hitches or glitches on any
device that is currently
supporting swift UI for on
device. So I think that's iOS
13, and onwards. So good tips in
there some simple things that
you should be aware of, and also
some more intricate things and
ways that can actually make sure
that you understand where the
performance is going within your
process. So that's, that's some
details of the instruments
application that is packaged
with Xcode, which is a profiler
that you can use to analyze the
performance characteristics of
your iOS application.
definite must read really good
article. And I think this is
also one that you should check
out. So this week, about like
six articles for you exporting
data from unified logging
transitions in Swift UI unit
testing and UI testing the Swift
the hidden costs of
dependencies, how to create a
get of X to upload the Sims and
swift why performance tips and I
think you should shouldn't have
a look at all say So these
articles. So that's it for this
week. If you have any feedback,
please reach out on Twitter at
app Force One. I'm just a DM or
an app mentioned away. And I
really look forward to hearing
from you what you think of a
podcast and articles that link
in my podcast. Talk to you again
next week. Bye bye