Okay. So, we are here another day for another debate here at INIC. It's the second one.
We have the JavaScript framework first. And now we are heading into the debate of what technology
we should use in the mobile technology. Okay. So, okay. I present myself. I'm a Robin
Noles. I'm an enthusiastic on mobile technology. I started a consultancy firm years ago that
was focused mainly on mobile apps. We began working on native, in a native way with iOS.
Then we switched to give some support on Android 2. And then we make a little step into hybrid
apps. So, there is no discussion here that mobile phones are the most used devices now
by users. But now as developers or as a tech team, we have to decide what technology to
use. We have several. Now, that first came the native apps. So, we were forced to learn
about the native technology. Then, we have the hybrid approach, which led us to work
with web technology. And now, we are heading into the future, maybe, with some kind of
progressive web apps. They say that is like the hype right now. So, we are here now to
discuss that. So, for this, we found so experienced guys for defending every one of the, of every
technology. Okay. First, let's work to Jordi Miró, present yourself. He's an entrepreneur.
And he will be defending the hybrid apps, right?
Hello. My name is Jordi Miró. I've been building mobile apps since we built them with Java
mobile in 99. So, I've been going through all kinds of flavors in mobile development.
Nowadays, launching a new service using hybrid applications. So, I will try to do my best,
even though I'm pretty sure I'm the less technical one right now here, to explain to you why you
should go hybrid. Thank you.
Then, we have Ruben Sospedra, who is a senior full stock engineer at ULA Box. And he will
be defending native, you say. Right. So, hello, everyone. I'm Ruben Sospedra. I'm, as I will
say, senior front-end engineer at ULA Box, usual by ULA Box. It's an online supermarket.
Very cool stuff. At ULA Box, we actually do a lot of things in a lot of technologies.
We have hybrid apps. We have native apps written in Android and iOS. And also, we are building
the new apps, which uses React Native, then transpires to native code base. And, for example,
the web, which is the main source of finance of the company, is just PHP tweaks with jQuery.
Not fancy, but it works super well. So, that's where it matters. Yeah, I'll be defending
native disclaimer. I'm never developed in Objective C, nor Swift. But, Android and React Native
a lot.
So, and the last one is Alessandro Zanardi, who is a CEO and founder at CodeWorks. And
he will be defending that thing that they call progressive web apps.
Yeah. Yeah, I got the toughest one to defend at the moment. Yeah. Yeah, so, just a quick
word about CodeWorks. We met with our two other co-founders. I'm one of the co-founders
of the company. And we wanted to create a coding bootcamp in Europe that was at the level
of the past bootcamps in the U.S. How many of you know what a coding bootcamp is, or
have been to a coding bootcamp? A few. Okay. All right. So, basically, the purpose of a
coding bootcamp is to get people to start a career in DAC as developers as quickly as
possible.
It's a very intensive educational experience, where, in our case, you work for three months,
11 hours a day, six days a week. So, it's quite mystical, some people call it. All right.
And after that, usually, you come with zero coding experience or a little bit of coding
experience. There is a pre-course, there is the main course. And then we bootstrap your
tech career, connect you with companies. So, for anyone who's interested to get into coding,
get in touch with us, you find us online, CodeWorks.me. And we're here in Barcelona. Thanks.
So, very interesting lineup we have today. So, I will ask you to make a first round on
hybrid technology. So, first, Jordi, about the hybrid apps. What is to develop in hybrid?
What are the pros and cons? And tell us about some technologies that help us getting to
this problem.
So, and please don't hesitate to correct me if I'm saying anything that you know I'm lying
or that I'm not saying correctly what it is. So, at the end, when we're trying to build
mobile apps or web apps using hybrid approach, what you want is to leverage on the HTML5
plus JavaScript libraries, SDKs, in order to, with one source code, being capable of deploying
your application to multiple platforms. In a sense that it looks like native, even though
it is not, and take the advantage of the distribution throughout the app stores, throughout the app
stores, and try to gain speed, because normally you might have burst developers in web technology,
so you can leverage on that. You don't need to have the skills on native. But there are
some cons, and I was saying before, I used to visit yoadwaki.tv. In our case, we needed
DRM support. If you try to do that, there's only one way. So, sometimes the discussion
is pretty simple. It's business, it's technical, so just focus on what you need, how you want
it built, and most cases you will find the right answer on which is the way to go. So,
if you ask me four months ago, hybrids were not the way, because we couldn't build what
the business needed. In our case today, what we need is we wanted to be fast, we wanted
to have access to WebGL or Canvas, and in that case, in order for a small team with limited
knowledge and a lot of technologies, we said hybrids is the way to go. We want to build
fast, reliable application to deploy in Android and iOS, and hybrid applications, as someone
mentioned, it's kind of 2015-2014, might be, the good thing is that they are tested, they
are tested and they are reliable. It's not like five years ago, seven years ago. No,
you have a huge support, you have a huge community, you have amazing frameworks to work with,
and if you want that, if you want to speed, deployment, one source code, I think you should
go with it.
So, then we go with native. So, yeah. Actually, one note about it, is like, RAM will be defending
actually react native as well, as a native thing.
Basically, because it's native.
Yes, but the briefing is there.
I mean, you have a dog, but you don't see the dog, you still have the dog, right?
No, no, no.
¿There is preaching techniques.
So, it's kind of can be misplaced.
Okay, so, for react native or in native.
There are… I really into what Jody said, a neary person of the products, the choice
of…not the technology like an abstract thing, but the framework, probably the language also,
la arquitectura, tus decisiones, como techies, vienen de las decisiones de desarrollo de la industria,
porque si quieres construir, vamos a mover a nuestro territorio neutral, si quieres construir, no lo sé,
es súper divertido hacer microservicios, distribuir microservicios, pero realmente necesitas una aplicación monolítica
porque realmente estás desarrollando un comercio magento, ¿qué estás haciendo?
Right, so, first came the business, so, once you have the business requirements,
make a kick off, and then move on to the development process, where in the best scenario,
you will keep some stakeholders that they are going to help you to make the iterations, technical iterations,
right, so the process will be something like business says that we need to build apps,
in my case, for example, a TulaBox, then once I know that they want to have both,
covering both platforms, Android and iOS, and they are really into incrementing their revenue,
we make a few tests with Abreed, later with native, and then we choose native basically
because the team feels more comfortable, right, that's another interesting question point,
if you have a team, you already have seven developers and they know JavaScript,
then go re-ignative or, sorry, going Abreed or going progressive,
or going re-ignative makes sense, but don't go to Android or iOS,
because you will need to hire more people, right, so you also have a legacy in terms of people,
that's super important, and moving into technology,
the main downsides and are hard, believe me, are basically all related to the continuous integration,
continuous deployment, all this story, right, because it's quite easy to have like a pipeline
that runs the test for a code, which is designed to run in a browser,
because it's basically the most portable technology that we have right now,
but once you are coding native, you are building for a very close environment,
which is the mobile, the device, right, so you have to mock up the environment,
you have to, well, connect all the pieces, if you're using re-ignative,
you have the bridge, stay away of the bridge, it's dangerous,
and also the deployment, if you are not using code push or technologies like that,
which allows you to change your code base in the app,
in a way like calling an API, something like that,
if you are not using these kind of technologies, you are limited to the releases,
you have to push a new code to the store, then you have to believe that the user is going to download the new version,
yada, yada, yada, when you have a web or progressive application is the best scenario,
you just push something new to production and it's deployed, that's all.
So I would say that those are the main downsides.
For me, and that's my very opinionated statement,
re-ignative have something that is super cool.
First of all, that it's react, react on the base.
So it's not because I'm a react fanboy, something like that, but you have all the community,
and NPA models and all the stuff that's around the JavaScript community,
so that's really cool.
Also, you have the opportunity to be also your server with Node.
So you can hire 10 JavaScript developers,
and you basically cover the web, the server, and the apps.
And this is, well, you're basically cutting the cost.
I could be talking all the day, so I'm going to stop now.
Alessandro, talk to us about what are progressive web apps
and how you can approach this technique.
Yeah, so one of the good things is that all the,
many of the websites that Reben just shared with us
are through also for progressive web apps, right?
You can use React, but you can also use Vue,
or you can use Angular, or you can use Ember,
and you can do your front-end and back-end with JavaScript.
So there are many of the pros, I think,
are shared between the two.
So let's try to figure out what could be some guidelines
for when would you go for one or the other,
because I think one of the things that will probably emerge throughout the night
is that often, in this kind of thing, there isn't one thing that's like,
okay, guys, this is what you have to do,
and if you don't do this, you're idiot,
it's like no, it depends on your project,
on the team size, on the requirements.
So let's figure out what could be some criteria
to decide what way to go.
I've heard mentioning the team size
and the resources, also economical resources you have.
So the developers, what are the developers you're working with?
No, what technologies they're familiar with
and what's your team like?
How big is the team?
What are the requirements of the app?
What does it need to do?
Is it very intensive?
Is it a video game?
Is it intense from a point of view of graphics or animations?
Or it's just like a crad,
so it's a technical term for whoever hasn't heard it before
for just a typical app where you create, read, update, delete information.
All right, which is most of the apps out there.
So starting from this,
then we can start the site.
Okay, given our requirements,
what is the tool that's more appropriate for that?
So now I'm going to say what could be some of the pros
of using progressive web apps.
How many of the people here are developers,
just to get an idea of like,
all right, okay, a lot of developers.
All right, guys, how many people are working in a team
of more than five developers in your current job?
All right, so most are small teams,
that's interesting, that's interesting, all right.
So yeah, that's kind of good
for defending progressive web apps.
All right.
So one of the things that, for example,
you came to this debate,
you want to hear present cons,
you don't want to only hear happy people,
so let's start to put some grit into the debate.
One of the things, so Ruben inspired me just a moment ago,
saying about this speed of the cycle of development.
So one of the things we notice,
for example, in our course,
so we have students building applications
throughout the course,
and during every course they build three applications,
each student, all right,
a personal one and group one,
so we see them working as like developers individually
and in group with other developers,
and our instructors are familiar,
and we do React, we do just web apps,
we do React Native,
we don't do pure native,
so like Swift or Android,
but our instructors have worked those technologies,
so like we can compare a little bit.
So one of the things, for example,
that's kind of frustrating for developers,
I've noticed over and over,
is that when they work with React Native,
which is an amazing tool,
I don't think that I am against React Native,
I think it's a great tool,
but one of the inconveniences that I've noticed
is that when you develop in the web,
your iteration cycle is really, really fast,
like say you want to release a new feature,
bam, if you have continuous integration
or continuous development,
you ship it and it's out,
and immediately your users will start using it.
Not only that, even before that,
while you're developing your app,
you can go and inspect things
with that little Chrome developer tools
that makes our lives
so much easier to debug things
and make it so much faster, right?
And good luck with that
inside of the iOS simulator
or whatever you're using for that.
So yeah, but maybe you're a senior developer
and you're not that worried about it
because you have ways to debug
that are as efficient and you're really good,
but if you are in a younger phase
of your developer life or growth,
I mean, that will be a difference
because sometimes you spend hours
trying to figure out
what is not working in there
or even to get an idea
of layout each time
with React Native
and Native Apps even more.
You have to recompile everything
until you see it there.
So especially React Native is this situation
in the middle where you don't have
the integrated IDE
like you would have
for example, the iOS SDK, right?
So you're still working
with the app needs to be compiled,
but you don't have a preview
of what you're going to see until it gets compiled
and loaded into the device, right?
So if you know, like,
what is the size of this item
and then you have 50 pixels
and then you have to wait
until it compiles, it runs in the device
and it shows it's like,
30 segundos, maybe 2 minutes,
I don't know, depending on how it comes.
Each time you want to make a little modification
you have to wait those 2 minutes
and those add up in your development process.
It's kind of frustrating,
but they're also good sites.
So I'd say, I don't, again,
don't want to take too much time,
but that's one of the things we notice
that people get kind of frustrated over,
like recompiling every time
and having the thing reloading
and sometimes there are even bugs
that you just don't have to deal with
that side of the complexity.
There are other things we might mention later.
I think we have
big talkers in here,
so I have a tough job today.
So,
actually,
actually for you three,
feel free to pick the mic
and then respond immediately
or trying to stop them.
Yeah, yeah, because
actually I wanted to
thank you.
I wanted to ask you, Ruben, about...
I'm sounding. Ah, okay, right.
It's not too quick.
It's like half a second.
And it's like hot model replacement,
like you do with Webpack.
I mean, I work every day 8 hours a day
with React Native. It's like half a second
and you have fine inspector,
which is not as cool as the Chrome depth.
That's true,
but you can debug all the logics,
but not the views,
the build,
but it's like...
Yeah, you get the red screen
that covers your app and gives you the...
That's why you're doing something wrong.
Okay, so,
maybe it's a question for Ruben
and you, Jordi, because
what about the window hell?
I mean,
when programming with React Native,
I think that's a known
problem that they have
like Facebook actually had
this problem with their developers
that when working with React Native
and I don't know in the average apps
but you have like a lot
of windows opened in there.
It's like you have to use
the editor, you have to
have opened the...
actually the Chrome with inspector because you needed
and then the simulator
and then Xcode opened.
So what happens with this?
I have
the simulator
and then I have
it's a Chrome browser,
no, like
if the DevTools open,
so you have Deluxe, everything is breached here,
then you have the editor,
which I think is normal,
and if you're using Beam, you just have the terminal
with everything.
So you don't need to have the Xcode open.
Oh, okay.
So you have the window hell is that you have...
one more window,
one more window,
which is the simulator.
Maybe I'm lost.
I'm referring to a problem that Facebook
actually said about it
and they recognize that they had
the problem in the F8 event.
So...
Honestly, I don't know what they're doing.
I mean, actually, I mean...
No, no, no, but for real,
I mean, everyone,
React Native Apps, then you just build
and you don't need the Xcode
to have it open, to develop.
When you want to build,
then you have to open the Xcode
and build, but you have Fastlane,
Fastlane.tools,
which you can optimize everything.
You don't need the Xcode even installed.
You don't need the Xcode build,
Essential Tools, whatever, I don't know the name.
So...
No, maybe they are doing something
which is more complex
or...
We are building an e-commerce at the end, right?
Very well built, but it's an e-commerce.
Maybe they are doing something super cool.
Well, they are such a network.
But I don't know.
Ok, ok, and then...
Ok, so let's talk about
some developer concerns
about these technologies.
Like, what about the performance?
And I like the word
for everyone that wants to take it.
I think...
I think that's easy.
So, Marc,
you read, you want performance,
you go native, period.
The problem is
how much is that percentage
of real improvement
in performance that any of our
application needs.
So, it's like in general performance,
only one percent
of our apps or webs
have performance issues due to traffic.
So,
you have to be very...
You have to push the boundaries
of your application too much
in order to say that performance
is the decision
to go one way or the other.
Maybe, yes, if you're doing
hard games that need a lot of graphics,
this and that,
I would say that's a very clear
way to decide which technology to use.
But if not,
average performance,
that is what most of us need,
can be achieved in any of those.
So,
if you're doing performance
and you go to one of the extremes
that you really need that,
would, for me,
it would not be the key decision maker.
I very much agree.
I mean,
unless your app deals
with streams of data,
you're doing something like
live editing, some videos
or some very intense animation,
lots of effects.
I don't think
you'd run in any particular issues.
Never...
And we've not had issues
with the exception of...
I've heard some apps built with Ionic
in the
hybrid world
that had some issues
more.
And I've heard also that Safari's doing better
than Chrome on this,
which is kind of surprising,
because Chrome is kind of leading the way
in many other ways.
But actually on mobile devices,
it looks like Safari kind of eats
these apps better than Chrome
significantly.
But still, outside of those areas,
I haven't heard of problems.
I agree with everything,
just...
And clearly, if you want to build a video game,
probably just go to native,
because you don't know the feature of your game,
what's the limit
and so on.
But just one thing,
there is...
with progressive web applications,
you can use service worker,
which is a technology very easy to use
that you can...
it can boost your performance very well.
So it's very cool,
the service worker per cache
and the service worker per se.
They are very powerful technologies,
especially because we can be talking
about performance in terms of GPU,
CPU, that's one thing,
and then we can be talking about performance
in terms of loading time,
right?
So the cache is basically, after you load it,
the next time is going to be instant.
And that's another kind of performance.
Thank you, Ruben, for that.
No,
what I was going to say is that
I'm having a very bad time now,
because it's like, I feel like
this debate is like
participant versus
moderator, and it's like,
they are joining forces, it's come on.
It's like, okay, no, I'm going to do this
and
not so nice
thing here that is the app
install friction.
So what happens with this?
So, I mean,
the app install friction is that friction
that the user have in order to
from the user
reaches to your app
in the app store, for example, until
it becomes an active user.
Okay?
So, what about this?
And the friction of adding a shortcut
to your phone
in order to get to that
progressive web app.
Are you saying that it's huge?
Friction is there because
in order to conquer a user.
I made it.
I think that the problem is in order to get a user
and all of you, even if you're in the tech world,
you know that your marketing team
and your business team is always reminding you
which is the cac of a user and so
you have that
anywhere you build your app.
So you have the friction of installing
at the end we all have a lot of applications
on the phone, but normally you use
very little of them.
So the problem is how
and I don't think that it is
a problem on installing
the app versus
the web, progressive web application
on how I get to that.
It's a problem which is the value of your application
so you're dealing with that friction.
So build it.
It would be the same.
Anything to that?
The problem is the store.
For me the problem is the store.
The store and the process
but that's why if you go hybrid
there are a lot of things that you would not care
because you go through it
less times than what you would do
in completely native.
Well
I mildly disagree with this.
Obviously I'm here to defend progressive web apps
so I gotta throw
something in there.
So it depends
on your case but if you consider
the case where
you already have a website.
So let's say
your company has a website
out.
It's a news website
or it's whatever you're doing
but you already have traffic to that website.
And this is very
very common that all these companies
that had websites all of a sudden felt
like that they had
to have an app, a mobile app.
So they started creating all these mobile apps
for everything that we were consuming on the web
already.
So many people really install the app
for those things.
It's kind of rare because you go to the website
and that's enough.
And if they want to convince you to install the app
it costs them like
Google's calculated about $3
per user average.
So depending on your app it might be higher
or lower.
So if you already have users
coming to your web and using and consuming it
then
when I think when Google was
creating the way in this area
they thought like
if you have users that are recurring
come to your website often enough
then why don't propose them
to have that on your desktop
so that you can send them push notifications
you can give them a better mobile experience
because with service workers
the app will load immediately
will have a cash content, it can handle
if you're offline for some time.
So it's like your website on steroids.
Right?
I mean you're like making the line
thinner between
an actual app, like a mobile app
and the website now it's becoming
like an app, you know
a kind of dress app
and offers more features
and where that border is becoming thinner and thinner
as we go through time.
So I think the case is
if you already have a website
and you already have users going there
then there is
way less friction in my opinion
for users to install
a progressive web app
because the device itself
proposes the user, hey, why don't you
why don't you want a better experience
and what would you say? Yeah, I want a better experience
and so you
install, you don't have to go to the store
find it, download it, oh my god
this app is 80 megabytes
and then every two weeks they're releasing an update
and now on my iPhone every
six weeks I have to download
three gigabytes of data because
50 apps that I need to update
that is as a nightmare, right?
and then you end up using the same
three, four apps all the time
so that's kind of a smoother
process, you don't have people
that get cut off along the way
more user engagement, it helps you
push notifications to users
that might be consuming your website
so I would say.
Let's make some trouble.
First of all
I
I mean
Progressive is always going
like a step behind native
just because the time that we are
it's the new kid on the block
and it's a very immature technology
and this is fine
this is fine
but the
the service workers
at the end they are just trying to replicate
that with the native applications
and hybrid applications you already have the information
in your mobile
physically in the hard disk
so it's cool
but it's a step back
and about the friction
I think that we have to make a statement
very clear, it's the new kid on the block
and I have
two official information
one is from Nielsen
and the other one from Flurry Analytics
it's from Yahoo, Flurry
and it's basically that
Nielsen says that
86%
of the media consumed
in mobiles came from native apps
and Flurry says that
just the 10%
of the time that the person is using
their phone they are using a browser
so this is right now
I believe that but it's always the same two apps
it's like YouTube and WhatsApp
and Facebook and Instagram
I mean it's those apps
and like yeah those are native
ok but what about all the other apps
but you are still using it
you use those five ones
but since like I don't think
like everyone in the world works
and how many websites there are
or Instagram or like
I don't know but millions
millions of websites
I mean this is another statistic
if you want to compare you have to use the same method
right so the
first we are saying that
if you are having all the time
the user is on the phone
the browser 90% for native apps
so
if you want to compare with this
then we should say
if you have an app
which is I don't know
one year old application
how many of this time share
it has
compare to if you have a website
say one year website
how many of your browser share
it has that will be
I don't know the numbers
the companies that tried the transition
got a 400%
increase in traffic
one typical case is the Washington Post
who created the progressive web
app and it was like one of the
use cases that was published
everywhere and
they had a huge increase in user
engagement and consuming
content and things
so the companies that didn't have it
against the website
which is where most users
were going
maybe in 85
maybe
maybe
okay, so
changing topics maybe
I read about
some interesting I mean
reading because of these
I read about
that the Steve Jobs initial idea
is that at first
iPhone, because
first mobile, a smartphone
that
didn't have an app store
because he strongly believed
that to developers
to make
apps for the iPhone
using web standards
and this I read about
Forbes listed that
as one of
the biggest mistakes
of Apple
and then they moved back
but they met the app store
and then Google Play
came and whatever
so the initial idea was
to make it from web standards
and then install apps from there
so changing
because Steve Jobs was a hippie
at heart
so
changing that
I will make you one question
is app store
and Google Play store
is a global app store
good or evil
if you get rejected
very bad
I think that here
I would say
we are talking about mobile
if you consider that
mobile web store
or app stores are bad
go to smart TV app stores
that's even worse
and
Android is pretty easy
just push and it is there
the problem is when you push iOS
and you have to deal with these people in Bangladesh
who are testing your application
no disrespect to them
because they are from Bangladesh
don't get me wrong
the issue is
it's a black box
and we don't like black boxes at anything
because that's why
in our case in hybrid applications
very little
you have to go there
but it's the minimum
at least once
the way you design your application
you are smart enough, you go once
so that's a problem
that other has
progressive don't have it, they have another problem
but
you have to deal with the app store once
and with their criteria
which is a human criteria in most cases
and even if you are very big
you have to wrap
and say
and I used to work for Rakuten
who is the third largest e-commerce company
and blah blah blah blah
when we had a problem
it didn't matter, it comes to human relationships
and you phone a friend you have in Apple
who happens to know someone
and they even had
to have this flag
to say I need a fast approval
it didn't have it years ago
so deal with the app store
and say that your business guys hate
I'm going to release tomorrow
what do you sure know
ok, but not only
in the review process
but in terms of promoting
or in terms of being there
if you are no one
because you can be listed
on the first positions
or you can have access to that
as a fast track
to some reviewer
from the app store
the first dashboard of the app store
but if not
it's good, it's bad
because here the answer is quite easy
you have to choose
drone into the ocean
or drone to the sea
that's the only difference
because it's super difficult
there are a lot of competition
if you are in the market
it's right, at the market
at the end it's a platform
and it's a marketing platform
you are basically
going through a funnel
my app is about
finance
therefore I'll be
not in the website
competing with all the websites in the world
but I'll be in a play store
and inside the play store
I'll be in the category of finance
if I do
I don't need to have a lot of download
I just need to appear first
in the first 500
and start working on this
it's something that you have
with checkpoints
so that's better
bad side, all the review process
I've read once
in the States
I don't remember the company
but they made an experiment
with the Apple store
they just basically pushed the same app
like 11 times
at the 12th time they actually published it
completely random
actually a quick note
is that Apple
has shortened
this review process
a lot the last year
and I don't know if
some of these technologies
I mean, I'm sure
something is related to it
but I don't know what is related to it
before the review process
was like one week long
ok, and we were very happy
when the review took like 5 days
you were like
you felt important
and it's like
no, of course
no iOS developer
I mean
you are not an iOS, a true iOS developer
if you haven't been rejected once
100 a day
ok
that determines the level
of whatever
but now
the review process is one day
I think they are using
more machine learning behind it
there is less people
in Bangladesh
and more computers doing tests
and that sped it up a lot
and enter some edge cases
when they decided it's still human
but they are increasing
the number of things that are automated
and that gives the speed
that's my guess
I haven't actually talked
with Apple about this
just my guess
maybe your answer
about this
topic that you were discussing
let me make another question
because it's kind of related
to Progressive Web Apps
because Apple right now
I was going there I guess
ok, let's do it
Apple is the biggest wall
against Progressive Web Apps
Google is pushing
and Chrome is
supporting Progressive Web Apps
but
all the market is waiting for Apple
to make Safari support
Progressive Web Apps
implementing access to service workers
push notifications
and what's happening with that
great question
thanks for that
I was about
it's better
I'm going to make this auto-goal
because it's better
to say what's the main problem
at the moment
and not wait until they're going to bring it out
and kill me on this
so the main problem
the Progressive Web Apps have at the moment
is that Safari doesn't
fully support service workers
so that kills a lot
of the purpose of Progressive Web Apps
and it doesn't support the manifest
so the integration
with Safari is
I would say very shaky
at the moment
it doesn't do what
gives the main purpose
of having Progressive Web Apps
so Chrome supports it
Firefox is embracing it
and it's improving
Firefox
they were out of business already
and they're embracing
Progressive Web Apps
Firefox
good luck
they're embracing Progressive Web Apps
and Safari
for the moment is not
although for the first time recently
they put on the next
five years plan
that if the community
ends up going
Progressive Web Apps
they will include them in Safari
they know that they can't go too much
against the current on this
my impression is that obviously
there is politics and there is business in this
like
if you think about it
if Progressive Web Apps grow
in terms of distribution
it's
not particularly in favor
of Apple at the moment
because the App Store
it's a big asset for Apple
how much do they get in commissions
of the sales, of the apps that get sold there
so if you move a lot of those apps
it's a loss basically
for Apple in economical terms
in control, in power
in general
so I don't know if they can really enter this debate
in a neutral position
like oh yeah let's see what's the best technology out there
so I think they have a strong interest
at play and understandably
on the other hand to say something positive
about it I think some people have appreciated
the fact
is the eternal debate of like the world garden
Apple has always had this strategy
of like making things more closed
but
for the people that like Apple
with a better user experience
more filter, more control
better, more polished
more clean etc
so that
the people that would defend the App Store
could say that at the same time
there was like more quality
of the apps that are there, they review, they control
so present cons
but
for people that just love the freedom
of the internet and in fact
the web is built on this
on the possibility for anyone
to just bring your voice out
and
then let the public decide
is this worth my attention or not
is this interesting, is it bad, is it good
there is no one else making that decision
for you so far and I hope
it's gonna stay like that for some time
so in this case
more politically
more in favor of progressive
web apps
and I hope Safari will embrace it
and then let the public decide
what they prefer
oh, we have a question
yeah, thanks for the question
I was checking that
knowing that it could come out
as a question
so you can do that through the web
so the Apple
Wallet API
and Google Pay allows you to
put like a meta tag
in your web page
and if the device supports
payment, you can do the transaction
so it will check that you have
like a credit card in your Apple Wallet
and the device supports that
and when a user clicks on like pay now
or whatever, it will go through
the native device payment
procedure so that's actually nice
it works already
and it works on iOS devices already
maybe it works because
they are getting some money from it
maybe
I was just about
to start talking about this
because basically
I want to tell you two stories
short
first is the
after this, we are heading
to the questions
I think it's quite interesting
both of them
first of all is the story of the
technical committee of the web standards
I don't remember the name, TJ39
I think it's the name
and what's the problem
with the progressive right now
and it's basically
for a second
put you in the
in the boots of Apple
you are making
thousands of millions of dollars
every year and basically
like 60% of the revenue
comes from the app store
so why you should make
anything
period, not anything
don't move, right
you are actually doing the business
so the technical committee
like two years ago
started to
make a lot of improvements
like APIs, HTML5
APIs and so on
and the ECMAScript committee also
and well, all this stuff
they push the service worker
they push the pre-cache
they push the push notifications
which is
here comes the debate now
the push notifications
is one of the big assets of the native apps
that's super important
maybe not for the techies
it's hard to understand
how to go to the user
whatever time
whatever the user is
I mean you have a lot of information
related also with geofencing
and that kind of stuff
which is basically metric
the position of the user
and so on
all this stuff which you can only do
if you have an open standard
for the web or the native
and the push notification brings the debate
because
there are a lot of applications
without doing some tricky things
from a web
obviously with the native yes
but from the web
and this is a super blocker
this is a super blocker
so what Apple said
I will open the push notifications
on iOS when you make me
the payment API
so like two months ago
if I don't remember but
the technical committee say
it's a push notifications API
therefore this is
probably the start
of the way to progressive applications
I don't want to
stab me in the back
but that's true
and what Alex said
is right about the open of the internet
that's one story
and the second story is
what this about the technical committee
means in a startup
in a company already
there is a
task job
it was to transform the
eulabox.com into a progressive application
and that was the first idea
what happened
we found the limitation of the push notification
the limitation of the payment API
and so on a more complexity
related with the iOS
then we go to our metrics
and we say that we saw that
like 85%
of our revenue comes from
then we
at November
October November something like that
we made the decision to go to React Native
and make native apps
because you cannot just
because it's super trendy and the new kid on the block
cut 80% of your revenue
so that are the two stories
you have something that is super trending
it's super cool and probably
probably
probably in the future
it's gonna be like the
default
but right now isn't
isn't in terms of
user time share
whatever
isn't in terms of market
isn't in terms of functionality
isn't now
so probably all the people that's here
you're building your business now
not in 2019
so
that's too far I think
Apple sale in the 5 next year
Apple sale in the 5 next year
yeah
push notifications
actually this is why we say that
the key of progressive apps
relates on Apple
yeah I mean
of course like once you have
you have payments
you have push notifications
you have service workers
then again this border line
between a native app
is because
we all agree that it takes more effort
to develop a native
app
especially if you want to go on both devices
Android and iOS I would say
because of course like you got to work
with different languages you have to
maintain two code bases
you have to push to the store
you have a development process that's a little more complicated
anyways more effort
more expensive
so if you take off the advantages
most of the times
you would be more inclined to go that
so
what are factors that we could
consider
now I completely agree with what Ruben said
if you're building an app
today in production
alright and you want to make sure
that it works on Android and iOS
I would go react native
or native
the main problem you would have
with progressive web apps
is on iOS devices
that's where you would have most pain
if you just want to target Android devices
then
would you go for one platform only?
more consider
there are people that just release an app
sometimes also you might want to start releasing an app
to one audience and then the site
there is a lot of business cases
sometimes you want to see how that works
you want to get it out fast
see how many users you get and then the site
in the future hopefully this will change
maybe it's going to be faster
it does depend on Apple
another aspect that we haven't talked about
I think it's quite important
and fascinates me
I also
love user experience
I don't know how many of you are into UX
but yeah
that's kind of a big topic
I'm just going to throw it out
when you go web apps
so progressive or not
the app dictates
the UI
so it's the app that chooses
and how the user should use it
when you go
native whether it's pure native
or it's react native or whatever
then you embrace the operating system
UI
so that's not entirely clear
I mean good practice says
so far that it makes it more comfortable
for the user if you follow the operating system
UI because they are really familiar
there are apps that are so much used
and if they end up
they can get to a power position
where they will almost dictate
the UI themselves
because you are so used to have it that way
and in a way
I mean even the operating system
if you look at how for example
the Apple operating system has evolved
they have tried to bring
the two UIs very much together
you start seeing now notifications on your desktop
that have like the great background
but it's not necessary why they are doing it
because they want to make it feel the same
they are copying each other
going in the same direction
so eventually that
I think that is a very interesting consideration
who is going to lead
the UI
is it going to be the operating system
or is it going to be the app developer
and what users are going
to prefer
and that's interesting
if you do use progressive web apps
and want to be consistent
with the operating system thing
then you require a little extra effort
I think I guess you can all guess
how that is more painful
because you have to detect what device the person is using
and then provide two different type
of interfaces based on that
when we get
when we get then to progressive web apps
the discussion will be bootstrap
or material design then
so
so
that was my comment
so
may I answer
because I think
at allabox we are right now doing this
and it's not
really something about
who leads
but the learning curve of the users
if we are doing the same patterns
again and again and again for the user
it's super easy to start
exploring your application
I mean if I show you
three parallel horizontal bars
on the top left
of the screen you will understand
that if you press there
the drawer will appear
so this is a pattern at the end
we try to replicate these patterns
and what is true is that you have different patterns
on iOS
and on Android for example
in iOS there is no hardware back button
that's a pain in the whatever
and
just this thing
if you are doing native
you can access the native components
which they are already
styled in the native way
so I mean if I get a spinner
in Android or in iOS
it's already styled
it looks like Apple once
or Android once
that's less worth to do
at the end
how difficult is to break what users are used to
and I think that
if you are really really big
you can set up your own
your own ways of going
the problem is for most of us
we are very small
so we need to stick to what the user
normally is used to
rather than trying to
I mean I agree
I think
there are some things where
everyone would agree like
that's kind of a design pattern that's working
and the user is familiar with
there are other cases where maybe
the user is used to your website
that has that thing in that way
and doesn't want when they go to the mobile
having a completely different place
so
they have also to consider that transition
from the website to the mobile app
and not only from one mobile app
to another mobile app
just to know what the factors at play are
and so that's
for consideration of the developer and the team
each time to make I think
just consistency
consistency
he's right, if you are in this trouble
go to analytics
and see if you have more mobile traffic
mobile leads the way
and if not it's text up
nice, so
questions
there's a mic
okay
how do you control the
the quality and the security without the filtration
which the app provides you
you don't
meaning, well
one of the things that progressive web apps
has done
to improve in this area
is that
all the apps they want to have the progressive
web apps advantages
need to be served through HTTPS
and a valetial as certificate
so that is one step in the direction
so like at least you know
that information that's passed between the app
needs to be secure
and you know
so that is to protect
the user to a certain extent
there is no filtering
so that's the web
I mean that's the web, like who
can you publish a website that's bad
if it's super bad people eventually
will come after you at some point
depending what you do and how relevant you are
but like
so there is no censorship
at the beginning
on the API
I mean when using some progressive web apps
I think that there is some
checklist that you have to
that you have to embrace
and one of the things is that you have to use
HTTPS
and if you're not using it
you cannot use the API
that the progressive web
app exposes
who's not using HTTPS
yeah that's a good question
ok I will say that
what I'm saying
is not because of this
specific thing
but that they have like some tools
to protect the user
against that
that's all I think
so more questions
ok no questions, I'm surprised
yes
why would you choose react
over real native
it's a matter of
the team that you have
matter of maintaining the cool things
I like the thing on react
on real native
ok got it
at Dullabox it was
first because of the team
we already have
three JavaScript developers
continue
and second and most important
because the speed of development
so you're agreeing
if you want IOS and Android
you have to develop twice the same code base
and here
also a thing that they want to share with everyone
is that you actually have a pathway
from react native
to the progressive web applications
because for us, for example
that we're using all the fancy
stuff, relax
sagas and everything
the sagas, the containers
the actions, the reducers
the logic, the router
everything is just
JavaScript, it's not coupled
to react native, just the views
so we can and we actually
did and we tried and it works
we can have our
say
botboton.android.js
boton.ios.js
boton.web.js
if you are at web it's going to load
the boton and everything works
so you can actually use
react native
as
an extra tool to build
IOS, Android
and web
so I'm not advocating this
for production now
not now but in the
very close future for sure
that's something that we have to la box
we tested
we experimented with this and it works
it's not in production but once we have it
in production I would say go
to the boton because it's easy
and you can share like 80%
maybe of your codebase
it's always the same, there are the logic
which is the complex thing also
and just makes the same view
for different analogies
and there is also a repository
from Nicholas Gallagher called react native
web which intends to do this
thing automatically for you
so you can check it out
so we have
do you want this?
what's coming up in previous days
like chatting about this
also, I mean it's kind of
against the entire
discussion here but
one of the things to consider is like do you really need
an app?
consider if you actually need one
because it's not obvious that
make that consideration
because sometimes maybe
a good web or web app or whatever
it's enough
just something that
you enter all the process of developing
shipping and doing
is that important for your business?
will it drive more value?
because I have a feeling that there are
way more apps out there
than probably
actually use and bring value
to the user and lots of websites
that have apps that people just never use
they just go to the website
so we have a last question
that is a question
that was posted on the
meetup website
and it comes from nowadays
it's saying native
versus progressive web apps
it's not so much about tech
but more about user behavior
are users really to add to
home screen a website instead of
installing an app?
but I think it's a little bit what we've discussed
when you mentioned friction and then
when we were discussing I think
how you acquire that user
and yes you can push them
and the Washington Post
it's a great example
but we do the same with
native hybrid applications that you download
we push the user in order to download
the application and I remember
this very well when we were doing it at Wacky
one of the things was
if we didn't have a mobile application
you couldn't watch content so
in that business which is a business decision
you want to watch movies
the advantage of progressive web apps
is that the operating system does it for you
and not only that
you skip the process
you skip several clicks
but at the end there's friction
and friction is going to be there
by one thing is having
that amount of friction
no because if you drive them directly
to your application the friction is one more click
well but first you have
to put in
in place the process
and ask the user about it
so I really want to do it
and I will charge them in any platform
then you need to go there
then maybe you are not signed up
in the store
then you forgot the password
then something
and every grade
I totally buy it
give me ideas and we will discuss it
is Nisha the name?
is a difficult name
I'm sorry Nisha
I'm sorry Nisha
and then about the friction
I don't think that it's about
one more click or whatever
but it's about what we talked before
user experience
I always think in my mom
my mom knows how to install an application
through the play store
but once she entered in a website
and then appears something that looks like a pop up
that says at the home screen
she called me
what's this
what should I do
it's about UX
what did you say?