
Why most mobile development projects fail - bontoJR
http://clean-swift.com/mobile-development-projects-fail/
======
jrochkind1
I think PSD-driven development is inherently broken, and this post explains
some of the reasons why. It's not really unique to mobile, I've experienced
similar on web apps that attempt to be "drop a PSD, now implement this",
although maybe the problems are worse in mobile.

I don't really know what the better alternative is, that will meet the
social/business/workflow needs that are the reason PSD-driven development
happens.

Except that it will involve some attempt to find a way to be more 'agile', as
compared to the implied waterfall model in "we give you a PSD and you
implement it." Ideally, I don't think they'd be giving you "it should look
just like this" PSD's at all. They should be giving you wireframes and
appropriate assets as assets. But this will end up being 'more expensive'
probably, with more hours spent on back-and-forth and iterations, compared to
the waterfall ideal of "here, just do this."

Good software is very 'expensive' (in terms of professional developer hours).
It's why we live in a world of really crappy software.

~~~
emitstop
This problem is the bane of my existence as a css/html guy. However I don't
believe the core problem is what you suggest. Forcing designers to just work
within wireframes isn't going to work. Assets and wireframes is only a small
part of what a designer does when creating a good user experience.

I think the solution is going to lie somewhere inbetween, with designers
needing to expand their knowledge and working within tools that are based on
how CSS and HTML actually function instead of a program that allows you to
just place boxes wherever you want and hope its easy to code.

I've been following what these guys are doing over at BoxBox, they are onto
something big I think.
[https://keminglabs.com/boxbox/](https://keminglabs.com/boxbox/)

~~~
jrochkind1
Yes, I think if the designer is going beyond wireframes, they should probably
be doing CSS themselves. Ideally applying CSS to a live prototype that the
'programmer' developed based on the wireframe.

I don't know, I'm not sure what the solution is. But I'm pretty sure it's not
PSD-driven development.

~~~
emitstop
I assume when referring to PSD-driven development you mean to say the process
of having a designer design a non-responsive, static mockup which is delivered
the the front end dev team? I think this is important to clarify because a lot
of people tout Sketch as being the answer despite it having the exact same
pitfalls and issues Photoshop does.

[https://keminglabs.com/boxbox/dynamic-layout-
engine/](https://keminglabs.com/boxbox/dynamic-layout-engine/)

Check out this demonstration. I really think this is going to be the next big
step forwards for designers. I don't think they need to fully understand CSS,
the box model, flexbox, the dom, inheritance, etc to deliver effective
designs. They just need to be forced to follow these limitations of these
things within the design tool itself.

I think the idea is to make every change the designer makes reflect a nearly
identical change that the frontend devs are going to have to also make. For
example, text color inheritance is a notoriously hard thing for a designer to
grasp. If that was handled automatically for them, they are going to out of
necessity, create a more code friendly color inheritance hierachy in their
designs.

------
bshimmin
There's a lot that's slightly off about this (though there is also some good
material in here too, and clearly it's coming from a place of frustration
based on real projects - perhaps, I suspect, without a huge amount of
experience of the grass on the other side...), but one bit that particularly
struck me was:

 _When a client wants to build a web app, they understand they need to have a
good design, build the pretty HTML and CSS, with a server in the backend, and
some dev-op to keep the app running._

Really? Because I'd be glad to introduce you to many of my clients who
absolutely do not understand _any_ of that; in fact I had a conversation with
a client just two days ago where I explained, patiently and not for the first
time, what it was one of my backend developers actually did on a day-to-day
basis, and why that sometimes didn't translate into something visible he could
actually click on in his browser.

Most of my clients really just want a complete solution (often involving
design) and they don't know or care at all about HTML, CSS, AWS, or Postgres.

------
WoodenChair
Mobile MVPs done by lone developers on a contract basis should be about
getting something palatable and pleasant that works, not drop shadows and
exacting transparency effects. Save that for a second version or when you have
enough of a budget to get a designer that knows her way around interface
builder. Getting too caught up in making a MVP pixel perfect is a cause of
failure for both client and developer.

~~~
stcredzero
_Mobile MVPs done by lone developers on a contract basis should be about
getting something palatable and pleasant that works_

Truth be told, _something palatable and pleasant that works_ can be a very,
very high bar from a UX perspective. When software collides with the real
world, you get _a lot of complexity_. Even organizations the size of Google
and Apple can't produce a Maps app that doesn't do wacky stuff that seems
designed to frustrate the user while trying to get someone killed. By
comparison, how something looks is dirt cheap. (As usual, it's far cheaper to
_signal_ quality than it is to build it.)

When it has to deal with the "real world," mobile QA and UX is hard, and doing
it to a high level is probably greatly underestimated in cost while being
quite expensive. They say a picture is a thousand words, and seeing it
yourself is a few more orders of magnitude. If your only feedback is
logging/callbacks/snippets of text from users, you're only getting a small
sliver of the true picture.

~~~
WoodenChair
Your maps example is a straw man - everyone knows Maps is incredibly complex -
not a small MVP. And your point about how hard it is to get things right
further exemplifies my point which is not to get too caught up in pixel
perfect details. There's no time/money/energy for that.

If your bar is too high on the UX side, as a lone contract programmer who is
NOT the designer, you probably will have the same problems shipping as the
person described in the article. Real artists ship. Lone consultants cannot do
Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's
only job on the project is the interaction between code and design.

~~~
stcredzero
_Your maps example is a straw man - everyone knows Maps is incredibly complex
- not a small MVP._

Not at all a straw man. Maps might be much, much larger than a small MVP, but
Google and Apple have a lot more resources than a lone contract developer.
_You_ are the one getting caught up with scale. I'm talking about the
increased complexity of apps when they have to bump up against the real world.
I've been greatly offended and materially affected by seemingly arbitrary
choices made by a developer on a username field. Namely, that starting to edit
the username field would blank out the password field, instead of doing this
on start-edit of the password field. In a time critical situation on low-
bandwidth, this can leave a user with a password vault cursing, high and dry,
while the app starts this kafkaesque cycle of doing the most annoying thing.

 _Lone consultants cannot do Apple /Google/Microsoft/well funded startup level
UIs where there's a guy who's only job on the project is the interaction
between code and design._

If the aim is to make a substantive tool that stands up to real-world
complexity in UX, someone, somewhere is going to have to spend a lot of time
testing the heck out of it and make careful observations. Otherwise, the lone
consultant is just going to check off the requirements, call it a day, and
bill. The only alternative is to be really good about feedback, and implement
in such a way that corrections can be distributed in a matter of a few hours
or less.

------
pavlov
The problem is the waterfall approach of client->designer->developer. If the
first line of code is written after there's a supposedly "finished" Photoshop
or Sketch document, the project is doomed to run into all the fundamental
design issues explained in this post.

Yet often that seems like the only way to the client, who thinks that they
can't afford a programmer in the "planning" or "design" phase... Even though
it leads to an unpredictable budget explosion in the latter stages.

One solution is to have better tools for app design. Instead of PSDs and
handwaving static Invision clickthroughs, there should be a tool that allows
an app prototype to be modelled using real code and native mobile concepts
like navigation controllers and list views.

I've worked on such a tool, Neonto: [http://neonto.com](http://neonto.com)

It's not perfect (the code generation can never match a veteran programmer's
style), but for prototypes often good enough - and much more powerful than
clickthroughs.

Btw, Neonto is considering switching to React Native for the generated
projects. If someone's interested in that, give a shout to hello@neonto.com
and voice your opinion!

~~~
kpil
I came here to say that. I read this as an advertisment for agile
development...

It's a false savings to involve developers late, even if you have 'the
competence' in the project already.

I would suggest using a story mapping technique. (Jeff Patton)

But if the stakeholders are clueless, you get into the game too late as a
developer.

------
joeld42
As a mobile dev, this article kind of irritates me. It seems like the author
is trying to shift his responsibilities to the client or designer. Here some
tips:

\- wireframe first. At least on a whiteboard. Build the interface with stock
or ugly controls from that, iterate the interaction. Only once that is done,
send ugly screenshots to the designer to beautify.

\- I believe that every dev should have photoshop, and know the basics. You
shouldn't need a 24 hour turnaround to cut an asset or fix a small issue.

\- actually talk to the designer. Don't make the client be a middleman. When
you feel a screen is done, review it with design first. Try for pixel-perfect
accuracy, but don't get too hung up on it, often a five minute chat can
suggest alternatives that save hours of work.

\- always decide what screens will work in landscape, or portrait, or both, up
front. This is easy to forget and sometimes difficult to retrofit.

\- not the only approach but one that works for me, pick one device (screen
size) to be the "hero" device for a project, and build for that first, then go
back and and adapt for the rest. This works better if its a more constrained
device, as adapting to a larger/faster device is easier. I often use a 5c as
the target.

~~~
ajeet_dhaliwal
I disagree about every dev needing to have photoshop and knowing the basics -
even though I personally have done this in the past i have found it to
ultimately be a waste of time - something looks simple enough to change,
sometimes you get lucky, it is, other times, 20 minutes later you're looking
through photoshop menus/dropdowns. The designer know these tools the best, I'd
rather take your third point and talk to the designer and communicate that you
need him/her to be available to work through these points. There's so much for
a developer to know and be focused on without having to learn to use the
designer's tools as well.

~~~
ThomPete
I think you are looking at this all wrong.

Just like the designer would benefit from knowing how code works, don't you
think the developer would benefit from knowing how photoshop works?

I find it kind of interesting that a developer would even feel a reluctance to
understand one of the basic methods used to deliver to them what they need to
develop.

You are missing out on great opportunity to have an informed opinion, think
about alternatives, find potential business ideas from something thats not
optimal and in general just have a better and more productive relationship
with designers.

I at least realized that learning to code as a designer, even just a little
bit, both taught me a great deal of how to build things for developers, help
them solves problems that might require a different way to think about the
technical issue of something and not do stuff that are completely retarded and
impossible to do.

~~~
sbov
Not particularly. The parallel to learning how code works is learning about
UX/UI design, not necessarily photoshop.

The parallel to learning photoshop would be asking you to learn
vim/emacs/<insert IDE>, source control, etc.

~~~
ThomPete
No they are actually benefits from learning photoshop because you understand
what they are doing more technically. Adding a drop-shadow as an example. Or
doing a gradient with specific ratio, angle and so on.

You literally get access to the very parameters and their values you might
have to use.

It's not about learning how to use photoshop. It's learning how photoshop
works, just like I learn code to understand how most code work. That doesn't
mean I would call myself a developer who can code like a pro.

------
pavel_lishin
> _In a web app, you’re either the frontend or backend developer. In a mobile
> app, you’re the app developer._

Maybe if you're part of a bigger team. But if you're working on an app of the
same scale as this hypothetical mobile app - where you have a single client
who has a designer - you're pretty likely to be doing all of the front-end
stuff as well.

~~~
wvenable
Yeah, this article reminded me exactly of what it was like to do smaller scale
web development. When I got to that exact line in the article, I had the same
thought as you. There really isn't much of a distinction.

I think if you're on any project that has a 3rd party photoshop designer it's
going to go just like this whether it's mobile, web, or even desktop.

------
dasil003
> _Mobile development = frontend development + backend development + dev-op._

Sorry no, being a mobile developer does not mean doing backend and devops any
more than being a web developer does. In some cases you might have to do it,
and in some cases you might not. But there's nothing inherently easier about
the web.

Furthermore I find the whining about different iPhone vs iPad layout
differences to be quite ignorant of everything except iOS development. There
is no more controlled environment than iOS. Try developing for Android some
time. And don't get me started on cross-browser, cross-platform responsive web
design.

The bottom line is no development is easy, it's all a mess everywhere you
look. It looks pretty bad when you try to extrapolate the warts from your
particular corner of the dev world into an assertion that other developers
have it easier. Doing good development work is just plain hard, even when
working with equal share stakeholders and with none of the trust and workflow
issues associated with clients.

------
mwcampbell
The difficulty of converting a Photoshop design to an actual UI reminds me of
this passage from Paul Graham's essay "The Power of the Marginal" [1]:

> For example, it recently emerged that the famous glass artist Dale Chihuly
> hasn't actually blown glass for 27 years. He has assistants do the work for
> him. But one of the most valuable sources of ideas in the visual arts is the
> resistance of the medium. That's why oil paintings look so different from
> watercolors. In principle you could make any mark in any medium; in practice
> the medium steers you. And if you're no longer doing the work yourself, you
> stop learning from this.

In the case of mobile app development, it's probably best to let the
constraints and idioms of the platform, which the developer knows best, steer
the design. So maybe part of the solution, contrary to what the article
suggests, is to further collapse roles; maybe the developer should do the
design, too.

[1]:
[http://paulgraham.com/marginal.html](http://paulgraham.com/marginal.html)

~~~
ageektrapped
Amen. I couldn't agree more with this.

A lot of comments in the thread are commenting that the developer should be
able to slice up PSDs, but why not go further and be responsible for the
design and interaction. It requires empathy for the user and, let's say 100
hours spent on understanding fonts, colour and layout.

The constraints of the platform should absolutely guide the design. Fight
those constraints and the app will feel weird on the platform.

Most designers won't know the constraints of the platform, or won't care; they
want to make a design that's unique and beautiful and all that. The client (or
any human being) will look at the pretty pictures and love it. The eventual
user of the software _won't care at all_.

Designers make pretty stuff that demos well. Those designs are usually a lot
more work to pull off in code, though. In the middle of implementing those
designs, all I'm thinking is, "What a waste of money. No user is going to care
about this [animation|screen transition|custom look|beautiful settings
screen]."

This applies to web and mobile and desktop apps.

Look at the apps you use everyday. They're probably boring to look at.

At the least, if you're in the client position, get a designer and developer
together at the same time to hash out the app. You can probably get something
that looks decent, works well and costs less.

------
rdoherty
The first half of the post applies to web development too. Most designers
design for the 'best case' scenario and leave out all the tiny details like
error conditions, interactions, too much/little content, various screen sizes
and touch vs mouse interactions (hover especially).

Let's face it, nowadays unless you are designing a content site there is an
immense amount of work needed to handle all the complexities of designing a
web or mobile app. This is why things like Bootstrap or other frameworks are
so popular, they allow a designer or developer to cover 90% of those scenarios
and focus on the important things.

~~~
bontoJR
> This is why things like Bootstrap or other frameworks are so popular, they
> allow a designer or developer to cover 90% of those scenarios and focus on
> the important things.

You're definitely right, but this IMO this is a broken model.

Most of the times superior web apps and mobile apps are the ones with
extremely well curated UX, maybe even featuring a slim UI. OFC is the product
is very revolutionary, you can be still successful with trade-offs in UI/UX,
but the second one is far more important than the first one, if you have a
shining, super cool bootstrap template, but a horrifying UX, people will
definitely walk away and never return. If you have a decent UI, but an
outstanding UX, they will stay and give you suggestions (implicit and
explicits) in how to improve the UI as well.

~~~
throwanem
That doesn't impugn the model. Using Bootstrap to cover the 90% case, rather
than building from scratch, lets you spend more time and effort on solid UX,
rather than having to reinvent basic UI from the ground up.

------
jernfrost
Oh man this felt awfully familiar. I am so happy I left iOS consulting work
and instead built in house apps so I don't have to deal with stupid customers
and designer detached from reality.

In retrospect I think they should leave a bit more design decision to
developers and let them throw up a minimum design first. A design which works
well within the constraints and technologies of the platform. Then designer
can come with input on how to change that.

It is astonishing how much faster you can build an app if you don't have to
care about getting the UI pixel perfect according to some designers pipe dream
of what it should look like.

Customers should know this, because I don't think they have any idea of how
expensive it is to insist on very particular details of how the UI looks. If
you give more freedom and choices in how the design should be to the developer
you can get an app for a fraction of the price which is easier to maintain.

------
jordanlev
Oh how the grass is always greener on the other side of the fence! As a web
developer, I'm used to hearing about how mobile app development is so much
better because there's a sane layout system and you don't need to deal with
crufty old CSS. And how it's so easy to get native functionality, and the UI
is easy to make run at the coveted 60FPS, etc.

Nice to be reminded that as lucky as us developers are in the grand scheme of
things, we still have hard jobs and changing your tools or platform won't
solve all your problems but rather just gives you different problems :)

------
jbob2000
Part of me wants to grab these clients and shake them while yelling "You are a
software company, why are you farming out your core competency!?!?" These
problems arise because the client thinks that the software portion of their
business is just a tiny part of the picture. If the only thing your clients
use to do business with you is your mobile app, then you are a software
company. Full stop.

Why the hell did they hire a designer? They need a product manager. And why
are they building the entire solution in one shot? Build it in small pieces
and iterate.

------
throwanem
Photoshop-driven development is still a common practice in the mobile space?
That's horrifying.

~~~
pjmlp
It is a common practice almost everywhere I work.

When Photoshop is too expensive, we get Powerpoint-driven development instead.

~~~
sokoloff
While Photoshop is a terrible starting point, if it gets avoided primarily for
cost reasons, run away anyway.

~~~
1_player
It's not a cost reason, most likely it's management doing the mockups.
Powerpoint it's all they know.

~~~
sokoloff
That might not be so terrible. GP was suggesting it was due to cost, which is
a "run away like the building was on fire" signal, IMO.

If all management knows is powerpoint, that's what they should use to
communicate their ideas. It's no different than if all they knew was a napkin
and pencil sketch.

~~~
pjmlp
I is due to cost. I am aware of a few projects that were done with trial
versions of the software stack, almost all the way up to a few months before
delivery date.

------
Zyst
I think it's a bit naive if you think that Web Developers are cleanly split
into Frontend and Backend. Most of the developers I know, like myself, are
Fullstack. According to the Stack Overflow developer survey[1] there's more
Fullstack developers than any other kind of developer.

It just bothers me that the implication I got from your article was: "This is
why mobile is tougher than Web." You might think: "Alright but web doesn't
deal with some stuff mobile does, like offline data sync", but web does deal
with stuff that mobile doesn't have to consider, like making sure your
application is secure from XSS attacks, making sure all your backend endpoints
prevent Overposting attacks, and other security considerations.

And if you are freelance, usually web also has to handle devops. Although
sometimes the client does have their own setup.

Web also deals with considerations you don't in Mobile in general. Web is also
very prone to failure if you don't plan carefully.

On the other hand the part that mentions that you should break your
development into tasks is absolutely spot on. When I take a job I plan how I'm
going to do the entire application in my head, writing it down in the process,
then and only should do I give an estimate. It might be the single most
important practice in my job as a consultant.

[1]: [http://stackoverflow.com/research/developer-
survey-2016](http://stackoverflow.com/research/developer-survey-2016)

------
ThomPete
Just like the designer would benefit from knowing how code works, so would a
designer benefit from know how a developer works.

The biggest issue isn't lack of communication but lack of understanding each
other.

I find it kind of interesting that a developer would even feel a reluctance to
understand one of the basic methods used to deliver to them what they need to
develop.

You are missing out on great opportunity to have an informed opinion, think
about alternatives, find potential business ideas from something thats not
optimal and in general just have a better and more productive relationship
with designers.

I at least realized that learning to code as a designer, even just a little
bit, both taught me a great deal of how to build things for developers, help
them solves problems that might require a different way to think about the
technical issue of something and not do stuff that are completely retarded and
impossible to do.

And so now none of my projects fail unless I want them to.

------
beyti
Replacing "Photoshop" with "Design Resources", really slim and useful article
I think. Especially agreed to the "design + dev + dev-ops" responsibilities
are mostly neglected by the client and should be described within handshake
process as described.

------
halis
I don't understand the notion that as a mobile developer you have to do the
front end and the backend...

I just wrote the back-end for an iOS app, I had nothing to do with the front-
end and the sole front-end developer had nothing to do with the back-end.

We used a simple Rest API. Where is the problem?

~~~
jasey
I think the author was meaning it more in terms of MVC in the iOS project

\- Web dev -

Backend dev scope: Model, Controler

Front end dev scope: views

\- Mobile dev -

Where as with an mobile dev, their scope is model, view and controller code
(full stack)

Your thinking of it in terms of the whole mobile app being the front end and
the rest API being the backend. But the app its self has both "front end" and
"backend" code segregation its self

~~~
rayvinly
Thanks jasey. That's exactly what I meant. But you laid it out for me.

~~~
robmcm
It is a grey area, all web applications I work on have syncing, caching, local
storage and offline support. I can also think of many mobile apps that do not.

To assume otherwise is a bit of a generalization.

------
sickbeard
no.. that's not why they fail. They fail because the client wants the sky but
his budget barely touches the ceiling. Eventually the money runs out and the
thing falls flat on its face.

------
askyourmother
Most fail because clients are lied to. They are shown the high-res print ready
Photoshop glossies, and told "yes, you can have this, it will use all these
assets. And lots of browser control overriding interactions". Then they try to
actually build it, it is slow, uses the whole months bandwidth allowance for
the mobile user "my whole 10GB gone? But I only browsed the web..", and will
crumble under load.

The real problem is letting designers near the web. They were OK on print,
well, a lot of printers had problems with the designers as well. Hmm. Maybe it
is just the designers.

~~~
TheCoelacanth
The problem is designers only being responsible for the design and not for the
end product.

------
fsloth
PSD driven development is still a thing? Ugh. What tools are out there to
build the UI scenegraph directly from production assets? (there is Rightware
for automotive displays)

------
rampage101
The client is unable to understand the technical challenges, while the
developer cannot read the client's mind. Not a mystery why the project in
story failed.

I am more familiar with AndroidStudio than iOS programming, and it just feels
like a hackish piece of software. It looks like Eclipse, and the code is Java,
but it's really a stripped down version of Java with a lot of hacks and work
arounds. It seems like so much time is spent negiotating with the operating
system.

------
fleitz
Stop slicing PSDs and start writing code.

Coding shit from PSDs is like making a car from a drawing a 3 year old made.
It's so fucking stupid that only a 3 year old wouldn't realize it's probably
the most retarded way to design an app.

If your designer knew how to design apps they wouldn't be making PSDs, just
like no car designer would substitute photoshop for clay. The only thing
Photoshop is appropriate for designing is static images / webpages.

------
adamconroy
Interesting article for me as I just rolled out an app for a client and a lot
of this feels familiar.

Firstly I was lucky I didn't have a PSD driven design, but my client demanded
a fixed price quote, so I insisted they pay me to do fairly comprehensive
spec, including a clickable wireframe prototype, bdd behaviour spec,
architecture design, background, requirements, objectives....

I went with lo-fi hand drawn pages which I scanned and wired up as a clickable
prototype via [https://marvelapp.com/](https://marvelapp.com/)

In the end it was fairly successful for me, as the comprehensive spec allowed
me to estimate fairly accurately.

However I don't think it was the most cost effective outcome for the client.
Because of their rigid nature, instead of collaborating through the process
(aside from the specification phase of course), I built them exactly what we
agree and invoiced them and was paid. However, within a week of the first
pilot they had come up with about 100 hours worth of changes they wanted.

In the end I spent about 100 hours in the spec / design phase (which I was
paid by the hour), 300 hours building the app (which was a fixed price) and
now I have about 100 hours of changes to make.

If we had worked to a budget rather than a fixed price, then by my estimate I
would have spent about 400 hours collaborating and iterating (basically
removing about 90% of the time creating and writing a spec) and they would
have had an app which they were involved in crafting the whole way through.
Basically I think they have blown about 100hours and they have to live with
lots of little nuances that they would have otherwise been able to decide
upon.

------
mooreds
Really great explication of the collapsing of responsibilities of mobile
development. Remedies, as always, involve educating the client. Makes sense to
me.

------
madetech
If designers could use an interface design tool instead of some photo editing
software, then most of the problems go away.

Spending time upfront perfecting a piece of art isn't a sensible way to
approach design as its all make belief until you've written some code

~~~
bloaf
I feel like I must be on crazy pills for suggesting that the designer's
deliverable should be something like UWP XAML documents. I wouldn't
necessarily expect them to do any fancy data binding, but they should be able
to at least lay things out and maybe manually fill in some dummy data.

------
ourcat
This is why I'm a "createc".

Front to back end. Involved throughout the project process. Gets the job done.
Everyone happy. Fully managed (and often exceeded) expectations.

------
overcast
In a web app, you’re either the frontend or backend developer.

Riiiiiiiiight.

------
stevetrewick
> _As you are about to slice the PNGs..._

You realise that you have failed to communicate _your_ requirements to the
client, failed to do due diligence on the requirements and assets before you
signed the contract and badly mis-scoped the project based on your imagination
of what non domain experts should know about your field of professional
endeavour.

You are likely to be eaten by a grue.

------
k__
Im so happy that I never ever in my front-end career had to implement some
designers PSDs.

The only images I got where mocks with stuff I already implemented but needed
some changes...

On the other hand, I consider myself a software and usability engineer, maybe
giving greater focus to nontechnical aspects of software has safed me from
having to do what a designer tells me to...

------
feverishaaron
Or just ask your designer to work @1x in a vector app like Sketch, and export
PDF vector images for import into the asset catalog (Scale Factor - Vector
Asset).

[http://useyourloaf.com/blog/creating-scaled-images-with-
pdf-...](http://useyourloaf.com/blog/creating-scaled-images-with-pdf-vectors/)

\-- A designer

------
kinj28
For enterprise mobile apps - we are working to address this problem with our
docker like container platform with ready pre-built mobile app with a runtime
to run your cross platform hybrid web. feel free to ping and I will be happy
to share more details.

------
nbevans
Who designs mobile apps by slicing PSD files? Fire the developer who went
along with that idea!

------
ex3ndr
In our project (actor.im) we successfully separated logic (cross-platform!)
and make it work closely with backend team and we cover together all corner
cases. Making UI on top of this is very-very easy.

------
megablast
Pfft, if his biggest problem is the design, he is sitting pretty.

Also the designer should slice up the PSDs, that solves this problem.

------
phatbyte
Most of those design issues could be solved if they used (designer and dev)
Sketch or Paintcode

------
guelo
s/mobile/iphone/

Same issues exist on the other more popular platform but this article is only
about the iPhone so the title is wrong.

------
wiradikusuma
I dont understand why you need to slice PSD like it's Web dev in 1999. Does
iOS/Android not have something like "Bootstrap"?

