Transcript
[ Music ]
[ Applause ]
>> Good morning.
[ Applause ]
My name is Josh.
And I'm part of the Technology
Evangelism team at Apple.
Our team has the incredible
honor of working with
developers, like you, from all
around the world.
And our goal is to help you
create truly great apps.
And in these conversations with
you, we learn so much.
We gain an understanding of the
processes you take; the
challenges, goals, and
aspirations that you have.
We learn about the tricks and
tools that help you out, and
then those that hinder.
And although every story that we
hear is a little different,
there's an incredible number of
common threads no matter which
part of the world the story
comes from.
Now, when you think about craft
you probably first think about
design.
But as developers and engineers,
we craft, too.
After all, craft is defined as
skill in planning, making, and
executing.
It's to create or produce
something with care, skill, or
ingenuity.
Codes written by hand.
It involves incredible skill.
And there's an ingenuity to the
technique that we take.
The choices that we make when
building an app.
And I want to talk to you today
about that craft and care, to
bring care into your code, into
your storyboards and into your
products.
This might seem easy at first.
But with all of the demands on
us, as developers today, this
can sometimes be quite hard.
Skill with a given craft is
something that develops over
time.
It takes dedication, patience,
and focus.
It's about learning to enjoy the
process of getting there almost
as much as the destination
itself.
Now, part of this process is
also about converting those
things that might take intense
and conscious focus at first,
into habits.
Similar to driving, with
experience and practice, the
number of things that we have to
consciously focus on while we're
driving reduces over time
because we convert things to
natural, automatic habits.
And we can do the same thing
with app development.
And to do this, it means
developing great habits, as
opposed to poor ones.
When it comes to building an
app, there's a lot of details to
pay attention to and as a
developer, so many of these
details that we have to care
about, well, they're rarely
actually directly seen by the
customers who use our apps.
And yet, they can be felt in
such significant ways, impacting
performance, reliability, and
stability.
And so, there's a lot of
details.
And there's just not enough time
to focus on them all.
So, I'd like to spend some time
today reviewing some practices
that can hopefully inform and
enrich our work as developers,
things for us to work towards
integrating into our regular
workflows, such that they just
become habit and automatic.
This will save us frustration,
hassle, and waste of time down
the road.
Now, for many of you, I'm sure
you're already doing many of
these things.
But perhaps there are some that
haven't yet fully become habits
for you.
And maybe you'll be inspired to
practice them more.
So, first, let's get organized.
In addition to being an app
developer, I'm also a
woodworker.
I find that it's this great
escape from the modern-day world
for me.
But one thing that's for certain
is that beautiful, well-crafted
furniture, is much easier to
build in a clean shop.
So, if your bench is cluttered
and poorly organized, it's hard
to find the tools and materials
that you need as you work along.
You constantly just have to
shuffle things around to make
room for the work that you're
actually doing.
And, in short, everything takes
so much longer than it should,
and more accidents and mistakes
happen along the way.
Our team sees a lot of Xcode
projects each year.
And there's definitely some
practices that can help you make
sure that your work space is
clean, tidy, and in a great
position to allow you to do your
absolute best work.
Xcode projects benefit from
structure and organization using
groups.
This makes it so much easier at
a glance to see the files
involved in each section of your
application.
It can help you hone in quickly
when you're trying to fix a bug.
Groups are best used to organize
your project functionally in a
way that logically follows how
someone might interact with your
application.
We often see projects that are
organized by file type or maybe
just don't use groups at all.
And that doesn't really help
someone out later when they're
quickly trying to understand how
all of these source files relate
to each other.
Furthermore, it can really help
to make sure that your Xcode
project structure and your file
system structure actually match
each other.
Since Xcode 9, when you create a
new group inside of your
project, it actually also
creates a folder on disk to
house the files that you place
inside of that group.
This means when you're looking
at your project in source
control, or just browsing the
file system, the structure is
mirrored, and this will really
help you reduce confusion and
missteps later on.
Storyboards are an incredibly
powerful tool for building out
user interfaces in a visual
manner.
But we do come across a lot of
projects that build out their
entire UI in a single
storyboard.
And there's no reason to do this
thanks to storyboard references.
Use a different storyboard file
for each major section of your
application and then use
references to tie them together.
You'll find it makes it so much
easier to isolate individual
changes.
And it makes it much simpler
when working with larger teams,
as you can avoid the risks of
those nasty merge conflicts and
make resolving those that occur
way easier.
Just like you wouldn't put your
entire source code in a single
file, don't put your whole UI in
a single storyboard either.
Keeping your project file modern
is a critical way to make sure
that Xcode can help you out and
avoids the accumulation of
issues.
This is one of those tasks that
can really be a non-issue if you
take care of it regularly.
But it can really cause problems
down the road if you don't keep
up with it.
First, when you're updating to a
new version of Xcode, you'll be
offered the opportunity
sometimes to have Xcode update
the project settings and update
your project file to the latest
format.
So, unless you have some
critical reason not to do this,
we'd recommend that you do it
whenever prompted, or whenever a
warning appears in the issue
navigator.
Second, make sure that your
project is using the new Xcode
build system first released in
2017.
It offers significant
improvements in performance,
dependency management, and it's
absolutely critical to your
adoption of Swift packages.
Now, it's been the default build
system since Xcode 10.
And you can verify the build
system that your project is
using by looking at the project
settings found under the file
menu.
Us woodworkers, we tend to hold
onto small scraps, just in case
we need them someday until that
scrap bin gets so full that we
just can't work around it
anymore and we have to come to
terms with the fact that these
tiny pieces of wood that we've
been holding onto are never
really going to make it into a
project.
As developers, we have this
tendency to hold on to scraps,
too.
But it's a simpler decision for
us.
Since you've got your project
under source control, and you do
have your project under source
control, right?
Get rid of that unneeded and
unused code.
Don't just comment it out just
in case you want to pull it back
someday.
If you ever actually need it,
it's going to be in the history
for that file.
And you can still get it back.
Let go of those scraps.
Another pile that we really
don't want to have grow out of
control are warnings.
And to that end, establish a
zero-warning practice for
yourself and for your team.
Code should never be checked in
that contains warnings.
And you should treat warnings as
errors while you're writing your
code.
Just fix them as you go along.
We've run into projects with
thousands of warnings.
And in most cases, they've just
accumulated for so long that the
developer gave up and just never
had time to go fix them all.
Furthermore, if you're
maintaining a project like this,
you're not going to see new
warnings when they show up.
So, this is getting organized.
Keeping a clean workspace and
project, it's critical to the
long-term health and success of
your app.
So, organize your project with
groups.
And have those groups mirror the
file system structure.
Break apart those large
storyboards using references.
And make sure your project file
is up to date.
Clean out that old and abandoned
code and get to the root problem
of warnings, and fix them as
they arise.
Doing these things will make
your project more nimble and
your development workflow way
better throughout the life of
your project.
Speaking of source control, one
of the things that you should
always do when you're setting up
your project, is enable source
control.
We do actually come across a lot
of projects that don't use
source control, especially those
with solo developer teams.
Conveniently, when you're
setting up a new Xcode project,
all it takes is to ensure that a
check box is checked and your
project will be under source
control using Git.
Now, you can always go back and
see what changes you've made in
the past,
what's about to change, when you
commit your current set of
changes.
And more easily catch any sort
of errors.
So, now that you've got Git
enabled, there's a few things
that you should keep in mind in
order to make it more helpful
and effective.
First, keep your commit small.
Check your code into your
working branch regularly in
small increments.
And keep those changes as
localized and self-contained as
possible.
This will give you a path to
look back upon when later on you
need clues or you're trying to
sort out a regression.
And, meanwhile, it's going to
reduce your odds of introducing
a regression because you're
making those smaller changes.
Second, write useful commit
messages because there comes a
day when we all ask the question
that we wish we could answer,
what on earth was I thinking?
Your commit messages are your
notes to future self when you're
trying to recall under what
circumstances some code changed
and the reasons why.
Run your source control, like
you would for a large team.
Even if you were a solo
developer.
It means maybe branching for
bugs and new features.
And then once you wrap those up,
squash them together back into
the main or dev batch, and use a
clean and helpful commit
message.
Now, there are several options
and patterns that you can follow
for your source control.
We recommend checking them out
and finding the one that works
really well for you and just
integrating that into your
developer workflow.
So, that's tracking.
Source control is absolutely
critical to a successful, modern
app development workflow.
So, adopt it as part of your
project and embrace it as part
of your regular practice.
Keep those commits small and
write useful commit messages.
And finally, utilize branches to
help isolate and manage those
changes, bug fixes, and feature
work.
Two of the greatest contributors
to clarity and maintainability,
in my opinion, are code comments
and documentation.
They're a trail of helpful
breadcrumbs for your teammates
or your future self.
Some might say, "I don't need
comments, my code is
self-documenting."
I don't buy this at all.
Well-written code is clear in
what it's doing algorithmically.
And it's self-documenting in
that respect.
But it doesn't convey why.
Why was this code written in the
first place?
How does this code fit into the
larger context?
Nor does it describe the
rationale behind the approach
taken when writing it.
The best developers that I work
with, that not only write
incredible, clear, and concise
code but they take the time to
sprinkle helpful review comments
throughout that code, to guide
the future reader into the
headspace of the original
author.
Junior developers will likely
benefit from this process, even
more because you're experience
at the beginning of a project,
varies so much from at the end.
And the decisions that you make
at the beginning of a project
might actually be at odds with
the decisions made at the end.
So, what makes for a good
comment?
Well, a good comment assumes
that the reader understands the
programming language being used
and can walk through the
sequence and steps being taken
in the code.
And instead, it really focuses
on why that code was written in
the first place.
What's the backing for that?
For example, this is the kind of
comment that just doesn't really
add any value.
And yet, we see it all the time.
I'm assuming that most of you
have written some code in Swift
and could just figure out that
we're creating a string constant
here carrying that value.
But we have no idea what id is,
what it's used for, or why has
this been hard coded into the
app?
So, with a little bit of
commenting, we now understand
why this value exists and where
it came from.
But we can take this one step
further; names for constants and
variables offer additional
opportunities for clarity.
So, if you find yourself using
single letters like m or i, or
things like id or idx, it might
be a great opportunity to choose
a more descriptive variable
name.
Autocomplete in Xcode works like
a charm.
So, you don't even really have
to type anything more.
And it will always be clear
throughout your code base what
particular identifier, in this
case, is being used at any point
in time.
The benefits to documentation
are very similar to that of
comments.
But these scale throughout your
application and beyond.
As you write your own apps,
you're creating layers upon
layers of abstraction and
algorithms taking what would be
large and winding passages of
code and breaking them down into
tidy, testable, reusable
functions.
But if you choose not to
document these functions, you're
forcing yourself to actually
rewrite that documentation in
your mind every single time you
go to use that function.
Typically, by having to go and
revisit the implementation of
the function, look at how each
of the parameters are being
used, and figure out how it's
going to transform them to
provide a result.
In case you aren't aware,
generating a Dock stub in Xcode
is incredibly easy.
Just place your curser on the
first line of the function
signature, press option command
slash and all the placeholder
text you need will be generated
automatically.
Fill in the blanks and you're
done.
Option clicking on any usage of
that function will now bring up
your own documentation in the
same contextual quick help popup
that you've come to know and
love for the native SDK and
Swift standard library.
Comments and documentation:
They're one of these really low
effort but incredibly high
reward investments of your time.
And it pays off repeatedly
throughout the life of your
project.
So, aid future understanding by
sprinkling your code with
helpful comments.
Bring readers into the headspace
of the original author with
those comments.
Use descriptive names for your
variables, and fully document
your functions, properties,
Structs and Enums.
Next, I'm going to talk about
testing, and specifically, unit
testing.
And to do that, I want to
introduce Marshall.
Marshall is our Swift and
developer tools evangelist.
He's an incredibly brilliant and
kind fellow.
And he also happens to be a
walking, talking Swift-linter.
Every time I submit my code for
review, I brace for the tsunami
of insightful comments and
feedback to help me improve what
I've written in both form and
function.
But the other day, Marshall
nudged me in the right direction
on another topic, unit testing.
Now, I must admit, I don't
exactly have an impeccable track
record in writing unit tests.
It's not that I don't appreciate
the potential value in them or
that I'm necessarily new to
them.
It's just I tend to always leave
it to last.
And by the time I've finished
implementing the actual code,
the last thing I feel like doing
is writing a unit test.
Nevertheless, the other day,
while implementing the data
model for the new lab queuing
feature, in the DubDub app,
Marshall piped in.
>> And while you're doing that,
you might as well add a unit
test to make sure that the round
trip between the Struct and the
dictionary representation keeps
working.
>> Now, in my mind, I really
couldn't figure out how this
would be messed up in the
future.
But nevertheless, I listened to
Marshall and I put in a simple
round trip unit test.
I ran it.
And I felt this significant bit
of satisfaction when the green
check mark showed that the test
passed.
So, I submitted my changes for
review and I didn't think about
that test again until a couple
of weeks later, when we wanted
to include some additional data
in that Struct.
So, made the changes to the
Struct.
And I didn't see any issues at
runtime.
I'm done, right?
So, went to submit my changes.
And then I remembered to run
that unit test.
And sure enough, I'd forgotten
to change how the dictionary
deserialization was working and
the test caught it.
The bug would have shown up much
later, when we implementing the
UI.
And would have undoubtedly
wasted a fair bit of our time,
trying to figure out what went
wrong.
So, thanks, Marshall, for
reminding me to include unit
tests, as part of my regular
practice.
>> You're welcome, Josh [brief
laughter].
[ Applause ]
>> So, even for sections of code
that seem deceptively simple, as
this particular one did to me at
the time, it's so important to
write those unit tests.
With the malleability of code
comes the potential introduction
of regressions.
And given that we never seem to
have enough time to test things
thoroughly, let's put Xcode to
work as an extra set of eyes.
So, make the implementation of
unit tests a part of your
regular development practice and
run those tests before each
commit.
Also, unit tests are a key
component to continuous
integration.
So, you can get yourself set up
for that.
Tests are another one of these
hidden details that your
customers will never actually
see.
But yet, could mean the
difference between an incredible
experience using your app or a
very frustrating one when some
important piece of their data
has been corrupted.
There's forms of analysis that
you'll want to keep as part of
your regular workflow.
Now, some of these do require
some extra time investment.
But others can happen for you in
the background without you even
having to think about it.
One tool that can be very
helpful is the Network Link
Conditioner.
After all, app development tends
to be performed in homes and
offices with incredible network
performance.
But this really isn't a
representative environment of
where your app is likely to be
used.
So, by enabling the Network Link
Conditioner, you can
artificially constrain your
network performance to one
similar to that of a typical
cellular network.
Or even a poorly performing one.
You'd be amazed at the number of
issues that you'll catch with
loading and race conditions so
that you customers don't.
Inside of your scheme settings,
there's also several sanitizers
and checkers that can help
discover various issues
throughout your development
cycle.
The Address Sanitizer will watch
for things like memory
corruptions and buffer
overflows.
Memory issues are frequently the
cause of security
vulnerabilities.
So, using the Address Sanitize,
will help you make sure that you
don't ship these is the first
place.
By enabling the Thread
Sanitizer, while testing your --
and debugging your app in the
simulator, you can help discover
data races.
Data races are when you have two
threads that are not
synchronized and at least one of
those two threads is attempting
to do a write on the same piece
of data.
Now, these can be particularly
nasty bugs and they can have
programs acting unpredictably.
Or they can even result in
memory corruption.
The Undefined Behavior Sanitizer
captures bugs like dividing by
zero, out of range casts between
floating point types, overflows,
and misaligned pointers.
And when a program has undefined
behavior, it might cause a
crash.
It might act in unpredictable
ways, or it might act like it
has no problem at all with
different results at different
times seemingly with no reason.
Incredibly frustrating bugs; the
sanitizer can help you get rid
of them, before they can wreak
havoc on your project.
And finally, there's the Main
Thread Checker which ensures
that you're not performing
invalid usage of appKit, UIKit,
and other API's on background
threads.
For example, if you're updating
the UI on a thread other than
the main thread, it can cause
missed UI updates, visual
defects, data corruptions and
crashes.
Sometimes these bugs can be
really hard to track down
because they might only appear
intermittently.
Now, there's minimal performance
impact by having this enabled.
So, we just recommend leaving it
enabled whenever possible.
While debugging your apps, keep
an eye on performance and
resource utilization.
And make sure that your app is
being as efficient with system
resources as possible.
The first step is, use the Debug
Gauges.
These are found in the debug
navigator in Xcode anytime
you've built and run your
project.
Here you can check out CPU,
memory, disk, and network
utilization throughout the
lifecycle of your app, quickly
understand if your app is doing
something like connecting to
unexpected servers over the
network.
Or maybe it's constantly pulling
at an end point, and chewing up
a ton of bandwidth and battery.
And finally, you can take this
even further, by clicking in the
profile and instruments button
which will allow you to run an
even more in-depth analysis.
One particular instrument that I
use a lot is the time profiler.
This allows you to ascertain
which passages of your code are
taking up the most cycles and
has allowed us to narrow in on
passages of work that might need
to be made asynchronous.
Or perhaps, I just implemented
in an unscalable manner.
Analysis is a really broad
subject.
But most of the tools I
described here only require that
you remember to turn them on.
So, simulate typical and poor
networks using that Network Link
Conditioner.
Use those sanitizers and
checkers frequently.
And just leave them enabled, if
you can.
Refer to those Debug Gauges
regularly.
And just keep an eye on the
footprint and performance of
your app.
And dig deeper into issues and
address them with great
precision, by analyzing your
app, using instruments.
Turning these small efforts into
habits will go a long way into
improving the performance and
reliability of your apps.
Back when I lived in Toronto, I
had a single car garage that I
had converted into my
woodworking shop.
It was a cozy space.
And I had it entirely to myself.
But since moving to the Bay
Area, I don't have a space to
myself anymore.
And I've been using various
shared and community woodshops
in the area.
Now, doing so can be a bit
frustrating at times because now
I have to share the tools and
the equipment and the space with
others.
But something I hadn't realized
I would appreciate so much is
the opportunity to bounce ideas
off of others in the shop.
And get their opinions on ways
to go about doing things.
I think with app development the
analog here is that of code
review.
So, for many of the apps I've
built over the years, I've been
the solo developer.
And much like having your own
shop, it feels incredibly fast
and nimble because only your own
opinion matters.
But the drawback is that you
don't have that opportunity to
learn from your colleagues and
peers on better ways to use the
language, frameworks, and SDK.
Often, although there's lots of
ways to approach a problem,
there's often a better way.
Something that stands out in
terms of being more concise.
Or maybe is more -- has greater
performance, maintainability or
reliability.
Because, after all, just because
it works, doesn't mean that it's
necessarily right.
Or that it could somehow be
significantly improved.
At Apple, all teams have a
policy where no code makes it
into a project without code
review.
Our team has learned so much
from each other through this
process.
And our code is way more
consistent in its style, let
alone the improvements in the
reliability.
It also ensures that our entire
team is more familiar with a
broader set of the code base,
allowing the range of bugs and
features that we can each tackle
to be much wider.
Now, I have this fortune of
being on a great team of
experienced developers, which
makes this much simpler.
But what if you're running a
company on your own or are the
sole developer on your project?
Well, try to find a way to
connect with fellow developers
in your area or from around the
world.
And come up with a way to do a
code review exchange with them.
Maybe investigate meet-ups,
local conferences, and
co-working spaces.
So, now that you're going to do
code review, as part of your
development practice, what makes
a great code review?
Well, first, it means taking the
time to understand each changed
line of code.
There's no point in doing a code
review if it's just a quick
skim.
Second, actually build the
project.
Run it. Don't assume that the
original author actually did
this.
Especially if the last commit
you see in the history was a
merge.
Run those tests.
First, doing so reminds you to
check and see that there are
actually tests.
And that the unit tests pass.
Remember, that just because it
builds doesn't mean that it's
not broken somehow.
Read those comments and
documentation thoroughly.
I mean, there are comments and
documentation, right?
And then look for spelling and
grammatical errors.
Similarly, look for spelling
errors in variable names.
So, as a Canadian, I have this
long-standing habit of including
"u" in words like colour, which
drives my team absolutely nuts,
when they go and search for
color.
Ensuring consistency in the code
base helps with finding and
using these functions and
variables later on.
And again, it just saves time.
So, even though it might feel
like this process is slowing you
down in the short-term, it will
undoubtedly save you time,
money, and customers in the
future through the reduction of
potential errors and issues in
the long-run.
And your skills, as a developer,
will benefit significantly, when
you approach similar patterns or
challenges in the future.
As developers, we're all
endeavoring to create small,
refined, reusable and testable
sections of code.
After all, we don't want to have
to constantly recreate the same
code over and over.
Packages and frameworks offer an
opportunity to maintain that
code in a more centralized way.
And offer that functionality in
a portable fashion.
Not only through your current
app, but through other apps that
might be able to leverage that
effort.
If your app includes extensions,
by packaging up your shared code
between -- in a framework, your
binary size will actually reduce
because both your main app and
your extensions can actually
share that same framework.
Of course, creating packages
also offers the opportunity to
share your efforts with the
community especially with the
tight integration now found in
Xcode 11.
But even more than the code that
lives in your app, shared
frameworks, packages, and
libraries need to be accompanied
by great documentation, in order
to be useful to others.
So, embrace packages and
frameworks as a way to break
apart your code base.
This will also allow you to
scale your work across multiple
apps you might be working on and
maintaining.
Frameworks can help you reduce
the binary size.
And then you can, of course,
share your efforts with the
community.
But be sure to include that
great documentation.
The last area that I want to
talk to you about today is
dependencies, and, specifically,
understanding the benefits and
risks of bringing them into your
project.
Using Swift packages,
frameworks, and other libraries,
offers many benefits.
But before you start to use a
given package, it's really
important to know what's inside
of it.
And what could be potentially
coming along for the ride.
Make sure that you understand
what your dependency is doing
with data.
Ultimately, you're responsible
for the contents of your app.
And what it's doing with user
data.
Make sure that the framework
isn't collecting metrics or
device information that's
unnecessary.
And make sure that it's
definitely not sending that data
off device.
Note what other dependency, a
giving dependency, depends on.
And research into those, as
well.
After all, including a
dependency with dependencies now
means that your app is actually
riding on the security and
success of that entire chain.
And, finally, there's one other
possibility.
What if the framework breaks on
you?
What if it becomes unmaintained?
Or what if it just disappears?
It's really important to have a
plan on how you're going to deal
with each of these situations
anytime you're introducing a new
dependency into your project.
After all, your applications
future is now dependent on it.
So, are you going to be able to
fix the open bugs yourself?
Are you going to bring that
project in-house and maintain
it?
Or are you going to plan to have
to completely swap out that
dependency later?
With all of the necessary work
that comes with that task?
The use of external
dependencies, such as Swift
packages, can allow you to move
more quickly and avoid
recreating tools that might
already exist in the community.
But be diligent in their use.
Ensure that they only do what
you expect them to.
And absolutely ensure that they
respect the privacy of people
using your apps.
Make sure you establish that
plan of what you're going to do
if they break or otherwise go
away in the future.
If you make answering these
questions a habit when adding a
new dependency to your project,
it's going to payoff in the long
run, and maximize the benefits
of using them.
With app development projects,
it can sometimes feel like the
last 10% of the project takes
just as long as the first 90% of
the project.
But I think that by trying to
convert some of these practices
and principles into habits, you
can help avoid that feeling.
So, by effectively organizing
your workspace, you can work
faster and more efficiently
keeping focused on the actual
code.
Through the power of source
control, you can track your code
base with precision, reduce the
odds of regressions, and
expedite the investigation of
bugs that might occur.
By writing helpful and
meaningful comments and
documentation, you can reduce
the cognitive burden whenever
you revisit code in the future
and every time you make use of a
class, Struct, or function that
you've built.
Unit tests will save you at the
eleventh hour, from checking
encode that introduces new
regressions.
Sanitizers and checkers offer
ongoing analysis of your code
and they run in the background
without you even having to think
about it.
Gauges and instruments ensure
that you are being efficient
with your use of system
resources and they'll allow you
to chase down performance and
other issues, with precision.
Code review is not only a chance
to evaluate the style and
function of your code, but an
enormous learning opportunity
for developing -- for evolving
your skills as a developer and
sharing them with your team and
the community.
Breaking your projects into
smaller and reusable packages
and frameworks can help scale
your work across multiple
projects and allow you to share
it.
There's also those benefits to
binary size.
And finally, the use of external
dependencies, such as Swift
packages, can help you move more
quickly and reuse functions that
might already exist in the
community.
But be diligent in their use.
Understand what they do with
user data.
And establish a plan in case
they go away.
Including these practices as
part of your work as an app
developer will only add a small
bit of time to each phase of
your project.
But it will save you an
incredible amount of time, over
the long run, ensuring your app
is built to last.
I hope that this collection of
ideas and suggestions I've
offered you today, has allowed
you to think about how you too
can further improve your craft
as an app developer.
Practices you might incorporate
to allow you to raise the
quality and durability of your
work and conscious efforts that
you can turn into automatic
habits, that allow you to direct
your energy to the areas of most
importance.
For the people who engage with
your apps will feel that care
and love that you've poured into
your work even if they can't
exactly say why.
And you can take great pride in
what you have crafted.
Thank you.
[ Applause ]