You have built your app. It is nice and shiny and you and your team did everything to make it useful and exciting as much as you could. You love everything about it. What’s next?
No one will download it unless you are very, very loud. Even if people struggle to find your app the chances they’ll discover it organically are close to zero. So to get your first 1000 installs (or more) you need to hustle.
“Specification merely refers to the act of ‘To state explicitly or in detail’ or ‘to be Specific” (From Wikipedia, the free encyclopedia).
Is it really needed in real life, can the work be done after just a briefing?
– You are smart, you can figure out what to do.
– Oh, yes, I’m smart but not a mind-reader.
Building a good mobile app is much more than actually writing the code and publishing the resulting product to an app store. Rather than that, it’s a nearly endless process of iterating and evolving your app, so that it would meet your customers’ requirements at any given time.
We can email you this article right now, just click here.
In today’s economy, app creators are engaged in the tightest competition possible for users’ attention, and for a place at their home screens. With that in mind, there’s no wonder that the user retention rate has become equally, if not more important in the world of mobile than the number of the app’s actual downloads.
That’s the follow-up to the talk I first gave at #appbuilders16 conference in Zurich, Switzerland.
We’ll talk a bit about the most undervalued part of mobile security: ideas and concepts. Another name for this talk could be “Everything Will Be Broken,” but what should we do?
Intro: this is the picture
Let’s take a look at the problem domain. What’s on the landscape? The picture shows our typical infrastructure—an iOS app talking over some network connection to a server where we have some custom logic serving our tasks.
Typical infrastructure of iOS apps
So, what do we care about while we’re making apps? User experience, fast & continuous delivery, and getting things done. And Swift, of course. Swift is very exciting!
What don’t we care about? Server crap. Everything not iOS is magical and unknown :)
Imagine you put on the Security Wizard Hat. What will you see?
Over the past few decades a significant portion of the economy has shifted. Once companies and services were geared toward enticing you out of your money. Today what many are after is your time. Instagram is free, and so are Snapchat, Facebook, and YouTube! While you’re not paying with your money, you’re paying with an even more valuable asset, time, or as we call it “attention”.
The economic and business model of these apps is pretty simple: they get most of their revenue from paid advertising. The more time you’re spending on a platform, the more ads on this platform you’ll see, and the more money advertisers will spend.
Our current version of the internet lives and breathes off a currency of human attention.
Are your QA engineers into monitoring apps’ traffic? Really, are they? The answer I usually hear is “why would I be?” Of course, this is irrelevant if your application works without access to a server and is purely offline. On the other hand, if your mobile app has network interactions, it is essential to make sure everything works smoothly there. Unfortunately, this part of testing is often used in web development but rarely used during mobile app development.
When I talk about analyzing app traffic I usually mean working with sniffers (that come in a form of proxy). These are special software that is intended to help you see network interactions in the form of HTTP or HTTPS requests and responses. While monitoring insecure HTTP traffic is relatively easy, working with HTTPS requires some additional actions (I’ll tell you about this in detail later).
Table of contents:
- Approaches to monitoring mobile application traffic
- Setting up your workflow
- How-to install a certificate on an Android
- How-to install a certificate on an iOS
- Working with proxy
- Optimizing your workflow with traffic sniffer
- When one proxy is not enough
Swift is becoming more and more popular today and has even become open-source! Personally I’ve been following its evolution since the very first version was released and already have two working projects in production. I’m very glad that iOS developers have such a great opportunity to use this modern and powerful language in their toolkit, but such a rush to new and not fully tested tools can sometimes lead to unforeseen bugs and time-consuming problems that no one has ever (or very rarely) faced. This might be one of the reasons people are scared of using new and fresh instruments.
Nevertheless there are different ways to try out new things. You can first play around with pet-projects or start adding new features to existing projects using new tools. I strongly believe that Swift is the choice of the future, though Objective-C will probably stay with us for a very long time.
To convince more of you to try Swift and save time by learning from mistakes I’ve made, I would like to share my experience of switching to this language after using good old Objective-C and discuss the differences between them.
Notice: This post was written while mostly using Swift 2.1 with Xcode 7.2 and migrating to Swift 2.2 in the end (no critical changes actually) :)
The new SFSafariViewController was introduced during the WWDC15 and it’s built into iOS9. It enables you as a developer to deliver data to the app from your web service (site), avoiding any need for authorization so that the user feels a deep level of integration between the web version of your service (site) and the client mobile application. We’ve already built this feature into our project and want to share our mobile app development experience with you!
We’ve made a PDF-version of this article so you can read it later. Download
Imagine the following scenario:
- User sign up for some service in web interface
- User receive email with an invitation code and AppStore “download button”
- User clicks the AppStore “download button”
- App is downloading from the AppStore
- When user open an app his/her profile and info is already imported into the app.
Mobile apps are created by individuals and teams, but used by thousands, if not millions of people, and you probably never will be able to see all users of your app in person. However, you can learn a lot of things about them and the way they interact with your product, and use this information to improve it and attract more customers.
While there are many things you need to know about your app and plenty of mobile app metrics to track, in the previous post we already made an overview of the performance analytics tools and platforms.
In this post, we will take a closer look at the tools and platforms for tracking app usage and marketing metrics. Fortunately, we at Stanfy have experience working with many of them, and can share our thoughts and recommendations with you.
Here’s a list of things we use at Stanfy to analyse how people use our apps and get the most important audience and marketing metrics.
We’re witnessing thousands of apps submitted to the Apple App Store and Google Play Store every day. As successful entrepreneurs we want our mobile app to be popular in the long term, generate revenue and have the love of users. The first step would seem to be actually starting to build an app without any initial research, but that’s like driving a car at night with the lights turned off.
Busy right now? We can email you this article right now, just click HERE.
Instead, try to validate your idea. This simple technique will help to save time and money before you actually build an app. In this article we will lead you through the basic steps of validating your mobile app idea.
This is my sketchnotes of Laura Klein’s, author of UX for Lean Startups, great approach to analyzing your product’s life cycle funnel.
No mobile app is immune to outages, errors, lagging and other kinds of unpleasant behaviour. There could be a million of reasons, from a typo in your code to issues with third-party APIs to incompatibility with certain hardware. Your task as a mobile app developer is to fight the problem and fix it as soon as possible – preferably before your customers even become aware of it.
The first step towards winning the performance battle is knowing your enemy, i.e. understanding what goes wrong, when, on which devices and how often. To obtain this information, you need to pick a set of performance analytics tools that would collect the data and provide you with valuable insights.
We’ve come up with a list of tools and platforms worth checking out that can help you significantly in your fight for perfection.
According to studies, one in four mobile apps is abandoned after a single use. So apart from focusing on first impressions and engaging users during the first launch you should think about how to keep bringing them back over time.
Very often a product’s life cycle looks like this:
People get excited at the beginning and open your app more often but after some time they forget about it or they find a cooler app in the same category and stop using yours.
Different apps have different usage patterns. For example, people may use weather or social networking apps several times a day, but if your app helps to find events in the city or provides yoga video lessons than it is fine if it is opened only a few times per week.
Ask this question before you start building anything: How can I ensure that users will keep coming back?
Getting user perspectives on product concepts and designs is an essential part of the product design process. A detailed understanding of the users, their needs and their goals is fundamental to creating a great product that users will love.
Users’ interviews are an exceptionally useful tool because it allows you to speak directly to users and get answers to specific questions that you have about your product. Moveover, interviews are especially valuable because they can help to uncover some issues or problems associated with using the product that were previously unknown.
All of us (well, almost all) work as programmers and love it when after a lot of work and the completion of a project we look back at the fulfilled tasks / written code and take pride in our work. However, there is a flip side to it. It often happens that after having worked on a project for a long time, you start to feel bored. Everything seems familiar; you get new tasks, but their basic nature is the same.
Wait, when did my work become so boring?
At such moments some people ask to be transferred to a new project. Others even change their jobs not so much to get a higher salary as to feel this change of pace by getting involved in something new they have never tried before.