Under the Radar

Under the Radar 39: Lightning Round 1


  welcome to under the radar the show

  about independent iOS app development

  I'm Marco Arment and I'm David Smith

  under the radar is never longer than 30

  minutes so let's get started

  so we decided to ask our audience on

  Twitter a little bit ago what we should

  talk about this week because you know in

  the summertime there's not a whole lot

  of news that happens in the tech world

  usually and so we decided this week to

  do something a little bit different

  we're gonna have kind of like a

  lightning round of listener Q&A and

  basically pick a lot of the tweet

  responses that we got and try to answer

  them in you know cuz like a lot of these

  things are not things that we can talk

  about it for a whole episode we just

  won't have enough to say on these issues

  to fill a half hour but we might have

  enough to say on them to fill a few

  minutes so we're basically pick as many

  you just see how many we can get through

  and a half hour and and see what happens

  from that so Davey when I get started

  sure so the first question that I was

  gonna answer is I got a question from

  Jordi Bruin who asked about projects set

  up when you are first starting new

  things and as somebody who starts a lot

  of new things a lot yes um I have a lot

  of experience at this and I've done a

  lot of different things I think where

  I'm gonna take his question with a lot

  of these I'm where you could be asking a

  different question then we're actually

  gonna answer and if that's the case

  sorry but that's the way this is just

  necessarily going to work so I'm

  imagining stuff like when you hit a new

  project woody how do you actually set up

  that initial Xcode project before you

  start coding and I've done a lot of

  things over the years I've tried all the

  different templates like when you go

  into Xcode and it has you know would you

  like this to be a tab to application

  would you like it to be a master detail

  view and there's all kinds of things

  that you can do you trying to set it up

  for core data or not or all these other

  sort of templates into this stuff I've

  tried all those in the past I've always

  found that at a certain point it starts

  to get really messy if I go hit check

  too many of those boxes and so at this

  point I would say what I do is I just do

  the minimalist or impossible

  so I do a single View application I

  don't check any of the core data even

  though I use core data

  I'll have the you know I'll go in and

  add all of those things later and I find

  that works a lot better so sometimes

  I'll make a throwaway project

  to see how the template would have set

  something up so if I'm curious if

  they've changed their core data stack or

  the way they recommend it or look at it

  but I just wanted as empty of a project

  as can be and I'll go into my app

  delegate I'll create my instantiate my

  first my root view controller and I'll

  present it and I find that doing it that

  way what I love is I know everything

  every part of the application from the

  absolute like from the bottom up is

  something that I understand and

  something I know it's working and so

  that I don't need these weird surprises

  that I find if I set it up using one of

  the Xcode templates cool

  yeah that's pretty I have nothing to add

  to that because I start a new project

  like every three years it takes a locked

  I I always forget what I've done last

  time and I just kind of wing it and kind

  of plow through your way sounds a lot

  better than my way

  okay yeah all right our next topic comes

  to us from Shore Johnson and who asks

  how do you know when an update is

  finished and can't be polished anymore

  startling that with myself now so this

  is you know this happens to every

  developer I know where like you have an

  update or even your 1.0 to your app and

  you could just keep making it better and

  adding a little thing here or there oh

  you know I get thrown one more thing I

  throw one more feature I could make this

  thing a little bit better I could

  redesign this one screen or this one

  element and when do you actually just

  say all right enough is enough I have to

  ship it and for me I've got I've you

  know kind of gone through different

  parts of this myself in my own

  experience like I've kind of gone a

  different into the spectrum here but

  ultimately I think it's better to err on

  the side of more frequent updates rather

  than fewer larger updates you know it

  you can't we actually talked a little

  bit about this a while ago about

  marketing and we're like you can hold

  back a bunch of features to release all

  at once in as I can marketing strategy

  to try to make like one major update

  that will be newsworthy enough for maybe

  some blogs to cover

  but in practice that's not most updates

  and the value of that itself is also

  kind of questionable it's it varies as

  to whether that's even worth doing with

  it actually works that way or not in

  general air now on the side of just

  release things as they get done and that

  tends to work better for me how about

  you yeah I would agree that in general

  the the thing that I've learned most

  after doing lots of updates is that the

  things that I think are important or

  interesting are very often not the

  things that are important and

  interesting and so the to my users and

  so the sooner that I can get it in front

  of people and get their reactions to it

  the better that the number of times I

  like I mean that I know this understand

  exactly that phase that he's talking

  about sort of if you're like oh what if

  I did this what if I did that what if I

  did this and you can keep doing that

  forever like there is no and what though

  you will never reach a point where

  you're like done this is perfect

  ship it you have to always be in sort of

  forcing yourself to cut it off

  and I think the more disciplines you can

  be to write off small things get them

  good and solid ship them and get

  reactions the better your app will be

  much more quickly and sometimes you look

  in it when you avoid probably more

  important that you avoid the situation

  where you go down this rabbit hole you

  build this like crazy new thing that no

  one uses or isn't important to the app

  or actually makes the app worse because

  you're you're doing it in a way that

  people aren't actually using your

  application for exactly so the next one

  I wanted to react to is a question we

  got from Rob Barney who asked

  essentially about the way we do UI

  layouts so do we code them do a dude

  interface builder or do we use a

  combination or you know in libraries and

  auto layout and all those kinds of

  things and so I I think I have a

  slightly strange view on this at least

  compared to a lot of people I've never

  really met on someone else who does it

  the way that I do it but this just works

  for the way my brain is so I do all of

  my layout in code for the most part I'll

  do have a few interface builder files

  usually those are for things like

  setting screens or kind of one-off views

  that aren't dynamic or interesting

  they're just kind of like something like

  a little part of the app you know a

  little corner of the application that I

  don't want to do in code but usually I

  just write them in code I do all my

  layout in in code as well I don't use

  auto layout instead

  do you know dynamic and interesting

  layout things but I do it all in like

  view to layout subviews or equivalent

  methods and the view controller or the

  view depending on what it is

  every time the views frame updates

  I'll go through and update the frames of

  all of its sub views appropriately and

  which is essentially what Auto layout

  does but I do it in a way that for me I

  can understand that I can be you know

  you're right clear declarative you know

  code that says like I want this to be at

  this percentage of this thing and I

  could do that in Auto layout and maybe I

  would get some benefits but every time

  I've gone down that road of taking my

  layout code and it will take my layout

  and putting it into something else

  whether that's interface builder whether

  it's Auto layout

  whenever there's some kind of magic

  that's happening somewhere else it in my

  experience it come to that comes back to

  bite me eventually that there's gonna be

  weird edge cases or problems or things

  that just mean that I would rather just

  do it in code it's not for everybody you

  have to kind of be good at can imagining

  a layout in your brain without it's you

  know seeing it in front of you so if you

  can't do that then this approach doesn't

  work but that's what I do and a random

  like pro tip for any kind of UI layout

  things is that every UI view has a layer

  and every layer can have a border width

  and so one of the like the biggest tools

  I ever use for fixing and debugging

  problems with my layouts is taking

  whatever UI view I'm working with and I

  say view dot layer dot bordered with

  equals one which just adds a little

  black line around it which makes it

  incredibly easy to see where things are

  actually laid out on your screen black

  that's so boring you should be using FoF

  the the bright pink ugly color that you

  that nobody ever uses in reality so you

  always know that's what you're looking


  it's true but then I would need two

  lines of code rather than just one

  that's true all right yeah I actually

  have a pretty similar answer to that

  question where I do occasionally use

  interface builder for something but it's

  rare I I prefer to do things in code now

  I actually do use auto layout more than

  just like a view layout sub views kind

  of thing where I I will I will use

  constraints and constraint and language

  but I do it through the library that I

  have open source called compact

  constraint and it's basically a kind of

  shortcut CSS looking kind of language

  for declare

  constraints manually and I use a

  combination of that along with the

  what's called a visual format language

  the kind of ASCII language of

  constraints like the ASCII art thing I

  don't know what it's called yeah I

  believe it's the I think it's called

  visual foreign language anyway I use a

  combination of those two things so

  basically my layouts end up you know

  there is a there is a coat there is a

  function somewhere maybe it is view

  alejo subviews or awake from neighbor

  whatever you know me there's a view

  somewhere in my code there's a section

  where where for every view I have listed

  like here's all the constraints for when

  you create this view and it looks kind

  of like CSS and it makes it very easy to

  see what's going on and to change what's

  going on and one of the reasons I do it

  this way and one of the things I don't

  really care for about using interface

  builder is when you're using an

  interface builder to do things it's it's

  often difficult to add a glance see what

  are all of the what are all the rules

  and all of the property changes from

  defaults that I'm applying to this

  object you know it when interface

  builder a lot of times things are buried

  in in checkboxes somewhere or like the

  little value changes deep down somewhere

  like you might miss if you're gonna

  cleansing glancing at the file whereas

  if you do the layout and and

  customization of properties all in code

  you can see it all right there you can

  see everything you're doing to this view

  or to this window or whatever the case

  may be and it makes it a lot easier to

  find and fix problems and a lot easier

  to figure out like oh what's going on

  here like why why is this thing bold or

  whatever you can see it all in one place

  and that's something that you can just

  never get really an interface builder

  alright my next question comes from

  William Robinson asking failure putting

  an app out and nobody caring slash

  downloading so basically what happens if

  your app just doesn't go anywhere this

  is heartbreaking it happens though it

  happens to everybody you know ultimately

  what if it starts going somewhere and

  then stops and then you know eventually

  sales reach negligible levels this has

  happened to a number of my apps because

  again this happens to everybody and you

  know one of the one of the clearest ones

  was bug shot where I just kind of shot

  up you know made made a couple thousand

  dollars in the first few months and then

  just kind of went down to nothing and

  was making like a dollar a day for

  awhile at best and you know that's when

  that happens you

  you kind of have to face reality and

  it's it's a little hard to judge like

  okay well if I put a lot more effort

  into like a 2.0 maybe I can like save

  this or rescue this usually that's not

  the right move usually you can't save a

  rescue it usually the market is telling

  you something the market is telling you

  either you know either we don't need

  this or we are satisfied by other neat

  by other solutions to this problem

  enough that yours isn't necessary and

  you know you could change things about

  it like you know you could change the

  price maybe you could you know again you

  could release a 2.0 but usually if

  something has failed in the marketplace

  enough that you need to face this

  reality chances are any of those changes

  you would make to it would not be enough

  to turn what is clearly a failure into a

  success you might eat a little bit more

  time out of it a little bit more money

  out of it maybe but probably not

  chances are you know recognize your

  recognized failures early enough and

  then just move on if you can that's

  usually a better use of the time than

  then like you know shoving more time and

  effort into an app that has already

  failed in the market yes and I have

  failed a lot like the experience he's

  describing and some that I've

  experienced many times I've watched a

  lot of apps and I've had many of them

  that go out and either have the thing

  you describe with bug shot where it's

  like he goes up and then just like falls

  flat or even I have just had it never go

  anywhere like you just never know and

  the biggest thing I suppose is to

  understand that it is not like the

  ultimate the Beth of ultimate product

  that I am building throughout my career

  is myself like what I want is to at the

  end of the sort of have each project of

  everything of each thing that I build

  make me a better developer make me more

  able to make better and more awesome you

  know products and send things down the

  road because tastes will change

  platforms will change like all of those

  things are always going to be very you

  know evolve over time and no one product

  is going to last forever you know my

  business and based on products in the

  past that

  dude kind of terrible but that was fine

  they had their moment and sometimes you

  know you never are gonna know exactly

  what's gonna happen and so when I

  whenever you have failures I think the

  most constructive way to look at it is

  to say what can I learn from this how

  can that you know how can this

  experience have make make me a better

  developer and then take that experience

  and just pour it into your next thing

  because as long as you are getting

  better each time then you're being

  successful like you are meeting the core

  goal and while that's nice when it's you

  know you hit on a product that is

  successful and really just takes off and

  like that's awesome you know I'm just

  really not diminishing that but making

  sure that you always keep it perspective

  that like the individual product is not

  to you

  you know you trying to have some

  distance from what you create is really

  helpful and keeping the focus on what

  can I learn and now let's go work on the

  next thing I not get too stuck on it all

  right we are sponsored this week by

  Braintree learn more at Braintree

  payments comm slash radar why make

  payment integration more difficult than

  it has to be brain trees powerful

  full-stack payment platform allows you

  to accept nearly any type of payment

  from any device with just one

  integration its flexibility your systems

  needs and supports most programming

  languages so whether you're using java

  god I hope not you have my sympathy Java

  Ruby or Python you always have a range

  of server-side and client-side SDKs

  available the Braintree code supports

  Android iOS and JavaScript clients and

  it tastes just ten lines of code to

  implement Braintree makes payments and

  your job a whole lot easier

  learn more at Braintree payments comm

  slash radar thanks a lot to Braintree

  for sponsoring our show okay so the next

  question I wanted to address is from hip

  tommcatt and he's asking about

  architectural patterns like mvvm MVC

  coordinators I have had a few quiet

  questions about this like the all of

  these things do kind of I don't I don't

  go and maybe my answer will probably

  point out that I don't go down the road

  of paying too much attention to a lot of

  these things that there's a lot of

  things that I keep hearing about where

  people are talking about like new

  patterns or sometimes there are new

  structures or approaches to apps or

  Mike and I see that and I look at it and

  I the thing that I always worry about

  whenever I see people who get really

  wrapped around patterns and this goes

  back to like back in my old Java days

  where the like design patterns thing was

  a big like there was like a big fat or

  is that was the whole thing everything

  had to be a factory or an observer god

  and the important thing I always try and

  keep keep in mind again and like when I

  get gonna people ask me this kind of

  question is making sure that you're

  writing code that a you can understand

  and and know that you understand like at

  a vague level how it works but you can

  under you understand why it's structured

  the way it is like the worst

  implementations of everyone ever was

  back when I used to do consulting where

  I'd come in to a project and have to try

  and work out how they're doing something

  and you kind of clearly get the sense

  that they're using a design pattern

  because they feel like they should but

  they don't really understand what that

  design patterns intent or purpose was

  and so it's just a mess so if you're

  ever going to use a pattern you have it

  should be this thing that it's like well

  you know this is the best way to do it

  I completely understand the trade-offs

  on both sides of this and for me and the

  way that I think about this problem this

  will work really well and if one of

  these approaches works great having view

  models or coordinators or whatever it is

  like that's that fits with the way your

  brain works then awesome that's great

  but definitely never feel like you have

  to go down the road of adopting some

  pattern because it's sort of hip and

  trendy because the nature of hip and

  trendy is that it will change and it

  isn't necessarily changing because we've

  somehow like had this breakthrough

  discovery and now it's like turned the

  world of software development over time

  like there's an element of it that it's

  just trendy and so find what works for

  you and make sure that you can

  understand your code and it's

  understandable you're gonna have far

  fewer bugs then the thing where it's

  like oh well theoretically if I use this

  thing and I completely abstract all of

  my logic away down the road it'll make

  it easier and I'll have great

  encapsulation and my bugs will go down

  because I can you know test all my

  interfaces and that's great that's

  probably true at a certain point but the

  actual like developer sitting at the

  keyboard has to

  understand what's going on and if you

  can do that then great like for me most

  of my architectural patterns in my apps

  ie are structured around like single

  thins and managers I guess I call them

  you guys the way most of my apps are

  caps all my app logic is kind of broken

  up into you know have a whole bunch of

  Singleton's that handle a bunch of Jeff

  like have a particular domain so I have

  a single thing that handles all my stuff

  with health and dealing with health kit

  or dealing with core data or doing

  networking and for me that works like I

  can I know where all like all the

  problems with that like there's

  certainly issues the singletons and

  coupling and like I understand those

  downsides but for me it works great and

  I understand it and I know how not to do

  it wrong and that's what I do and I try

  not to be too distracted whenever

  there's like some hip new thing that's

  come out and you know it's like you have

  the problem of you see a talk say at a

  conference or something or blog post and

  someone's like hey we did this thing and

  it worked great for us and you

  immediately can try and extend that to

  say like hey they did this cool thing

  and it'll work right for me when if you

  really you have to have a much more deep

  understanding of what that thing is and

  what its benefits are but before you can

  ever make that kind of a judgment yeah I

  I pretty much agree with everything you

  say I also developed with a lot of

  Singleton's and things I also don't use

  a lot of design patterns or lead the

  Gang of Four book and and so maybe I'm

  using them without even realizing I'm

  using them but I never really got into

  that side of software architecture of

  like really obsessing over that kind of

  thing because in in the scale that I'm

  typically working at with you know a

  one-person team that kind of stuff tends

  not to matter as much as it would maybe

  on a larger team and I'm working on

  pretty simple things and also like you

  know I just tend to follow the

  conventions of the system I'm in so like

  I'm very familiar with the way Apple

  does things with the cocoa API is and

  the way they're structure and kind of

  the the patterns that they encourage and

  that they use themselves and I try to

  structure the rest of my app that way to

  kind of mesh well and and kind of mimic

  the structure of the cocoa api's beyond

  that I don't really do any kind of other

  fancy structure all right

  next I wanted to bring up a question

  from Luke Allen whose ass

  about the viability and landscape for

  new indie developers to break into the

  iOS and Mac marketplace in 2016 now this

  is obviously a big and kind of broad and

  kind of squishy feelings question so

  it's a little hard to answer like you

  know can do Indies break-in now to me I

  think all you have to do to answer this

  question is to take a look at your phone

  homescreen and what apps are on it today

  and then think back or if you if you

  have old screenshots even better look

  back at what your home's what your home

  screen look like three years ago and how

  many of the apps that you that you're

  using today were out three years ago I

  bet it's not that many you know that is

  even ruling out like apples built in

  apps or anything which even they have

  changed quite a bit

  but the fact is that yes this is a a

  large and saturated and old market

  however there's always churn in every

  software market there's always room for

  something new and it isn't always easy

  to break in but there's always a spot

  somewhere in the market like you know

  simple things like that you think would

  be very very crowded like notes and

  weather apps like you know we bring up

  these examples a lot I mean there's

  always a market for a new notes or

  weather app if you can do something a

  little bit differently some people will

  like yours some people won't and that's

  okay there's a room it's a very very big

  market lots of people use it not

  everybody wants the same things out of

  every app and a lot of times people just

  kind of get tired of what they've what

  they're using and just want to look at

  something new so there's always room it

  is oh it is getting harder to find that

  room and there's more people vying for

  it however there is always room for new

  things to break into the market yes and

  I think the key thing when you're if I

  was if I was a new Indies trying to like

  source if I decided one day that that

  was what I wanted to do I want to be an

  independent software developer I would

  be very careful about aid like my mood

  check my motivations make sure I'm doing

  it for the right reasons and like

  understand how terrible of a job it is

  and not just sort of get which I can say

  a bit jokingly but quite honestly as

  well like it is not the it is it is not

  like a glamorous lifestyle being an

  indie software developer that there's

  only some upsides Oh

  being your own boss and being able to

  work on things that you think are cool

  but there's a lot of really not-so-great

  things some things that you give up from

  working for in a corporate job or in a

  consulting job so you know you there's a

  definite some trade-offs make sure

  you're doing for the right reason and

  then making sure that you're have you

  having realistic expectations about what

  you are hoping to accomplish you know is

  it that your goal is to in you know just

  have a side income from your Biff from

  your indie work it's gonna be your

  entire income and understand that those

  different levels are going to require

  different amounts differing amounts of

  time and luck and effort and be careful

  about what you're going after

  you know like sort of like you said like

  some apps there's a natural trendiness

  to them and so it makes sense to get

  into something and you know be some of

  that's similar anywhere there's a lot is

  a lot of churn like a weather app is

  something sort of comes to mind there's

  something where there's there's this

  natural like I don't know everyone just

  thinks of something differently and so

  you can have a unique take on something

  and that has has an opportunity to be

  successful and it also say be really

  careful about taking on projects that

  are very complicated to start with like

  you either need to be have some if you

  have some like really deep and

  interesting new approach to something

  like I think of someone like Chris Lucio

  with all of his audio processing stuff

  that he does like he he has made a

  business of making software because of a

  really specific skill set that he has

  that he really is good at audio

  processing and so he can make a business

  because not a lot of people can do that

  and so if you have a skill like that

  like run with that if you have some

  background knowledge or some domain

  expertise like go for that and and

  pursue it and but if you don't don't get

  sucked into the trap of trying to like

  build this grand big very like it's just

  like this existing thing but like way

  bigger and more complicated yeah that

  never breaks that's gonna really come

  back to bite you especially if it's just

  involved like oh it's gonna be a to

  sinking and it's gonna have all these

  other stuff and like that would be

  something I'd stay away from and

  especially to start with like

  start simple start with something you

  enter you enjoy something that if you

  made the app and no one downloaded it

  but you had it and could use it every

  day that you would be happy and that's

  probably a good place to start all right

  the next question I wanted to address is

  from Phil Koury who's asking about unit

  testing for the one-man shop is it

  worthwhile and if so where to start so

  unit testing is a midcity epidemic topic

  for me as it is something that I've

  never done so I can speak to it only in

  the theoretical rather than in the

  practical experience type unit testing

  is something that I have used it in the

  past like on different projects but not

  no never mind II work and I would say

  unit testing in my experience is useful

  for one of two reasons

  it's either useful because the cost of

  messing something up is very high so if

  you know if you're someone who's writing

  software that you know is used to

  control a plane it's flying through the

  air you need some unit testing like you

  need some serious you know quality

  assurance kind of process because if you

  mess up that really like like genuinely

  bad things can happen not just like bad

  things like my server went down for a

  few hours like you know life and death

  kind of situation so if you're if you're

  in a situation where the cost of having

  him having a bug having a mistake is

  truly you know significant absolutely

  and the other situation where in my

  experience unit testing is helpful is I

  know like there are some some developers

  I've worked with over the years for whom

  like developer unit testing is the way

  they think of development that they

  create you know sort of like the

  test-driven development approach or

  saying like here's this problem I'm

  going to code a test that will you know

  be global pass once I've solved that

  problem and then they go and solve the

  problem and it's just a like a construct

  that is helpful for the development

  process and if that's helpful for you

  then like you're probably you know if

  you're that kind of person like I'm not

  that person I like

  maintaining unit tests is one of the

  things that it like destroys my soul

  more than anything else in it because I

  feel like I'm building the app twice and

  I hate that feeling I what I value most

  in my development is being fast and

  efficient and um not doing a lot of

  ceremony around the development like I

  just want to get into Xcode I want to

  you know write the codes and ship them

  and unit testing because like I'm

  building two apps and one of them no one

  will ever see so that's my approach to

  unit testing yeah I'm pretty much the

  same I think if I had to write unit

  tests for everything I did I would stop

  programming all right one very last

  thing very quick thing here from Pete

  who asked things you now know that you

  wish you could have told your younger

  develop ourselves when just starting out

  so we only have time for maybe one each

  so my one is going to be that your

  actions in your app that you do to your

  customers are way more important in a

  competitive landscape than what your

  competitors are doing it's like if you

  if your app already has people using it

  it is yours you it like they are yours

  to lose people don't usually flee to

  other apps because of some competitors

  feature that attracted them over there

  they flee to other apps because your app

  is sucking in some way you're neglecting

  something you're not addressing

  something you're not facing something

  you're being too slow to to adapt

  something new whatever the case may be

  your customers usually yours to lose and

  so what you do is way more important

  than what your competitors do absolutely

  I think my best advice that I would give

  my younger self is that nobody has it

  all together and this is most I guess to

  address this sort of like the imposter

  syndrome kind of a problem that early on

  in my career I struggled with a lot and

  I still do in some ways but it's this

  it's so easy to look at someone else's

  output and judged just like judge the

  output not the process that it took for

  them to get there because it's easy to

  look at the output and say wow look at

  all like this is perfect it's like you

  know as though it was somehow like born

  like it was birthed magically into the

  world it's just this perfect process

  that was effortless and without problem

  it's like when the reality

  we all make mistakes we all have like

  the development process is often messy

  and uncomfortable and we have lots of

  failures some of those are public some

  of those are private but everyone nobody

  has it all together we're all just kind

  of like fumbling our way through and the

  the more I was able to wrap my head

  around that and be comfortable with that

  reality I did more honestly that I was

  just able to make better software

  because I was less worried about

  comparing myself to this impossible

  standard that I imagined other people

  were living up to and just did my best

  and that we worked there worked out a

  lot better well said all right thank you

  very much for listening everybody not


  eight topics in 30 minutes not bad at

  all that's pretty good yeah all right

  and we will talk to you next week