Welcome to the Native Mobile Apps Lifecycle session. In this session, we'll
be focusing on the application and deployment lifecycle of mobile apps so
we'll discuss how mobile apps are dealt with in lifetime and how we can deploy a
mobile app and what might happen once a mobile app is deployed when it changes
sometimes we may need to generate a new application package and other times we
may just need to tag a new version and then we'll also see the type of
information we can get about mobile apps in service center so let's go ahead and
get started mobile apps in lifetime have an
application version number we'll be able to see the modules of those applications
and then they'll be specific versions of the native mobile apps for iOS and
Android and the versions of the native mobile apps can be different for those
two types so when we look at the the native mobile app as we're deploying it
it has a normal application version inside of out systems and then the
mobile versions can have a version for Apple and a version for Android here
we're here we can see it's been generated for Android but it hasn't been
generated for Apple so when we're deploying a mobile app the native
generated app is not deployed to the destination environment so in this case
in our development environment the Android app has already been generated
and is ready so when we go to deploy this and we move 1.2 over to the quality
it says that the Android app needs to be generated but that it's not configured
so it will not actually move the generated app over it will just take the
configuration of the generated app over and then it will need to be regenerated
over here so for it to be regenerated it's going to need configuration
information about its key store and other types of information so we will
have to do an extra step after the deployment occurs
now sometimes we'll be changing a mobile app so the mobile app has been published
the native package was already created and depending on the types of changes
many times those changes are automatically updated and the
application package doesn't need to change at all but there are some
instances where the application package will need to change and that is if we
change the applications name the entry module itself the icon or the main color
or we add some type of mobile plugin that's going to access native features
or change the high-level configuration for the mobile platforms so when we go
to publish these types of things it can give us a warning about changing the
mobile app may require it to need to be regenerated so when we go to tag a
version of a mobile app there will also be the native app versions as well so
lifetime does not allow the tagging of a version of an app without tagging the
native build if it already exists so here in our example if we've moved up
from 1.2 to 1.3 or higher here we can see that it's changed and we have the
plus sign so we'll be able to tag this to the new version of 1.4 but 0.1 is no
longer the active version so it needs a new version as well so when we know that
there have been changes we're going to need new tagged versions both of the
overall application from an out systems perspective and the generated
application that we'll be targeting this specific platform
so when we go to deploy these if the native app that's configured in the
destination environment could be automatically generated then it will
change as far as the deployment stage is concerned so here when we're moving from
development to QA we if we don't notice any changes and everything is fine it
can actually generate that mobile app so this has now been scheduled as part of
the overall deployment process and that can happen with all of the new changes
when the deployment stage is moved so last but not least if we're in service
center and we don't have access to life time there is still information about
the native application package that is available in that particular environment
so if we go into our application we go to the native platforms tab it will show
us both an apple and an Android tab and in this case we can see that our Android
version is 0.2 and we could go ahead and download that if we needed to we could
go ahead and configure the overall versioning and if we wanted to
regenerate this application this native application package we could regenerate
it as well so that's it for the native mobile apps lifecycle and how we'll deal
with changing and deploying mobile apps and out systems thanks for watching and
have a great day