MoodUp.team, Author at Mood Up team - software house
React Native vs Real Native moodup team 12 2018

React Native Apps vs. Real Native Apps – Which Should You Pick?

Mobile apps have become an integral part of our lives, as are the apps that help in making life a lot more convenient and hassle-free. This is the reason why companies are constantly looking for ways that will accelerate and facilitate the process of creating mobile applications to meet market expectations. Not all smartphones, however, are created equal, which is why app developers need to pay careful attention to their operating systems, in order to develop apps that can run on the said operating systems.

Mobile Operating System Market Dec 2018

Statistics data from theStatcounter.

The question then boils down to picking between iOS and/or Android, the two operating systems holding the largest share in the app market. It isn’t easy, which is why we have a separate guide on picking the right platform for your app.

Once a decision on the platform has been made, the developers must then go about creating the code for the two platforms, which are very different. This is as time-consuming and expensive as it sounds, which is why React Native is fast becoming a favourite amongst the app development community.

React Native AppsAbout React Native

React Native is a cross-platform framework designed by Facebook to give developers the opportunity to create apps for iOS and Android at the same time. It is based on React, which is a Facebook library for building user interfaces and has been used in the creation of apps such as Airbnb , Instagram and Facebook due to its

1. Efficiency

One of the most important advantages of using React Native is the ability to save timethat would otherwise be spent on developing two separate versions of the same app. Such time saving allows developers to focus on creatingbetter code at a faster speed, which lowers app development costs for the client.

2. Modular and intuitive architecture

The modular andintuitive interfaceof React Native makes it easy for developers to migrate and implement quickly on the project. Thisincreases the flexibilityof the development team and facilitates afaster introduction of updates.

It is however not without its disadvantages

1. Not for all APIs

One of the biggest disadvantages of the React Native framework is thelack of support withsome native APIs, preventing it from being able to communicate with other applications, thereby affecting itsoverall functionality.

2. Design adjustment

The design adaptation may require writingadditional codeto avoid confusion in the application as Android and iOS platforms have seperate design guidelines.

Real Native Apps

Real native apps require developers to write separate apps for iOS and Android, unlike with react. Applications for iOS are developed using Swift or Objective-C while Android applications are developed using Java and Kotlin.

About Real Native

Do not discount Real Native just yet, as it trumps where React failed.

1. Best performance

Thanks to the native structure, applications are created and optimized for a specific platform, which makes them very fast, responsive and high performing.

2. Better harmony with hardware

The Real Native approach providesbetter accessto hardware such as  GPS, camera and microphone, which translates into enhanced performance and application capabilities.

3. Easy errors detection

By using basic languages for the chosen platform,the possibility of errors are fewerand can be detected as they happen.

The above however does not come without its own share of disadvantages

1. Higher costs

Making an application for two separate platforms require twice the labour, which translates into longer development and testing time, requiring the client to foot a larger bill.

2. Separate optimization

The two platforms require different levels of optimization to their inherent differences.  This is all the more pronounced when developing for Android, due to a sizable number of versions of its platform in the market.

Conclusion

React vs Native Benefits

The React Native structure is a solution that allows you todeliver applications in less timeon both platforms and provides many functionalities. It provides full support for the functions of mobile devices and ahigh rate of performance,which is why most clients prefer to use it for their apps. This, however, is not a standard and requires careful consideration of the project and its scope before deciding.

Got an idea for an app and not sure whether to opt for React or Real Native?  Drop us a line with your idea here so that we can get back to you with an estimate.

Lean UX Post 1

Should You Adopt Lean UX Principles?

In a mobile-first world where clients require faster development cycles whilst adhering to the same high standards of quality, UX designers were in limbo.

It is to fit these requirements that the lean standards were introduced to design, prioritising regular UX interactions with real customers over excessive documentation. Such an approach to design we’ve found is more agile, increase collaboration and allows the design work to be done as efficiently as possible, so that the client receives the best possible product at the lowest possible cost.

Lean UX Cycle

Basics of the Lean UX

The primary function of Lean UX is to be as agile as possible, reducing the traditional UX documentation and long hours spent in design meetings. The team, therefore, focuses on regular interactions with real customers through UX interviews and early testing.

“Design only what you need. Deliver it quickly. Create enough customer contact to get meaningful feedback fast.”
Jeff Gothelf, Lean UX: Applying Lean Principles to Improve User Experience

Such an approach to design, increasescollaboration, where everyone is considered equalwith no place for gurus or ninjas. This approach, we’ve found brings different perspectives to the table and initiates the simultaneous processing of tasks within the different members of a team.

What’s not to love?!

The lean UX process

Detailed deliverables are not a significant part of Lean UX, as the core purpose is to improve the product here and now.

The traditional requirements in a design brief are therefore discarded in favour of “problem statements” which leads to aset of assumptions, that allows us to create hypothesis statements

General questions we ask to create assumptions include

  1. Who is your user?
  2. What is the purpose of the product?
  3. In which situations it is used?
  4. When is it used?
  5. What is the most important functionality?
  6. What is the challenge in delivering a product?

Hypothesis

A hypothesis contains three components:product purpose, its importanceandthe personas it is important to.

Hypothesis Statement

Such hypotheses are useful as it guides designers throughout the process of designing a product. Deviations in the MVP are easily discovered when ones work does not fit into the hypothesis produced.

MVP (Minimum Viable Product)

What is an MVP?

Lean UX is all about creating the MVP – a product withjust enough featuresto give the end users asatisfying experiencewhile providing feedback for future improvements. Such minimum viable products are the reason for Lean UX design to flourish.

The MVP is created from bothbrainstormed ideas and the hypotheses, in order to build a product that has a minimum of all the key components. The MVP is then used to gather user feedback to improve uponprevious assumptionsand the quality of the product.

MVP definition

Such an approach to MVPs brings down the cost ofdevelopment, increase efficiency and user satisfaction.

How can one evaluate the success of UX design?

  1. Observation–  directly observe the actual usage of the product in order to understand user behaviour and possible problems.
  2. User surveys – a simple end-user questionnaire can provide fast feedback if user observation is not possible
  3. Usage analytics – building analytics right into the product helps validate initial use and provides application telemetry. This is an incredible way to be up to date with user feedback.
  4. A/B testing – Allows for the comparison of two versions of a product to evaluate and pick the most effective variant.

Conclusion

App design is a costly process, in terms of both time and money, which why lean design can be beneficial for most clients. Such an approach will ensure an efficient design for your app as it can integrate with the agile framework of software development, which we use at Mood Up.

Got an idea that we can help build? Tell us more about ithere.

Why testing mobile apps is so important

Mobile App Testing: Why You Should Always Do It

Demand for mobile apps is surging year on year, with 2017 topping a global app download of over 175 billion and consumer spending that exceeded past $86 billion. This offers a huge opportunity, with many players attempting to outshine their rivals to increase their share in this space.

Smartphones today are considered very personal devices, with users expectinginstant gratification and high performancefrom the apps they use.The haphazard release of apps, however, is not the solution, with many developers preferring to followan agile approach to development, supported by a robust testing plan, to ensure the endproduct is of high quality.

Users also tend to associate theirexperience of an app with the brand it represents.All apps that carry a brands name should, therefore, be tested rigorously to ensure it functions as it should, in order to prevent any harm to the brand it represents.

Another important reason why app developers should test their apps is compatibility, as there is a vast array of mobile devices in the market, with the number expected to increase to 6 billion by2020. App makers should, therefore, undertake rigorous test standards to ensure compatibility with the numerous devices and operating systems that exist.

Source: Counterpoint research, 2015

This might not be as big a problem for apps that run on iOS, as Android whose source code is open and shared widely with many OEMs.

An interesting example for this is Facebook, who continue to rigorouslytest new versionsof its products such as Facebook, Messenger and Instagram on over2,000 devices.

Conclusion

The smooth functioning of an app plays a key role in itssuccess, which is why we at Mood Up base our development and testing on Agileprocesses. Rigorous test standards play an essential role in ensuring thespeed,privacy,securityandUX, users expect of an app developed today and should be made a priority. Remember, there is no lack of great apps that failed due to substandard testing!

Why planning is so important

Why Is Planning so Important in App Development?

With over 7 years of experience in working with clients, we can safely say that no two clients are alike.Each client is unique, with some coming to us with a clear vision of the product, while some require our help in narrowing their ideas down to a product.  It’s as challenging as it sounds, but not impossible as we at Mood Up place a core focus on planning.
Continue reading“Why Is Planning so Important in App Development?”

How to code pt.1 RxJava Retrofit

How to code (pt.1): RxJava + Retrofit

RxJava is an implementation of ReactiveX library for observable streams of data or event by using combination of the Observer pattern (read more). You will find more info on Retrofit (here).

I would like to show you how to call RestFull API enpoints using RxJava and Retfrofit 2.0. We are going to show you how to switch Retrofit’s Services method to RxJava Observable as well.

RxJava and Retrofit in practice

Before we get started, let’s add needed dependency to your gradle:

compile ‘io.reactivex:rxandroid:1.2.1’
compile ‘io.reactivex:rxjava:1.1.6’

RxAndroid included classes to RxJava that makes writing reactive components in Android applications easy.

After that add retrfoit dependencies:

compile ‘com.squareup.retrofit2:retrofit:2.1.0’

If you are using GSON please add converter for retrofit. Converter is needed to deserialize HTTP bodies into your custom class model. If you are not using it Retforit deserilizes HTTP bodies into OkHttp’s ResponseBody.

compile ‘com.squareup.retrofit2:converter-gson:2.0.0-beta4’

Here is a list of official converter modules provided by Square:

  • Gson: com.squareup.retrofit:converter-gson
  • Jackson: com.squareup.retrofit:converter-jackson
  • Moshi: com.squareup.retrofit:converter-moshi
  • Protobuf: com.squareup.retrofit:converter-protobuf
  • Wire: com.squareup.retrofit:converter-wire
  • Simple XML: com.squareup.retrofit:converter-simplexml

You can create custom converter yourselft by using Converter.Factory interface.
Next dependecy will help us return Observable object from Services:

compile ‘com.squareup.retrofit2:adapter-rxjava:2.0.0-beta4’

Thanks to that we have defined Service.

public interface APIService {
@POST(“list”)
Call loadCar();
}

In order to switch RxJava observable only one change is needed:

public interface APIService {
@POST(“list”)
Observable<Car> loadCar();
}

 

Now let’s modify your Retrofit Builder and add CallAdapter and ConverterFacvtory:

public Retrofit provideRetrofit(){
return new Retrofit.Builder()
.baseUrl(“http://api.geo.org/”)
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
.addConverterFactory(GsonConverterFactory.create(new Gson()))
.build();
}

Right, now let’s move to some examples, shall we?

Example 1

We can start and call firstRestfull API method with RxJava. Let’s begin with creating simple example that will provide object car.
We are about to do some simple activty where we have included APIService object already and are ready to call loadCar using RxJava.

public class Activity extends AppCompactActivity {
APIService apiService;
@Override
protected void onCreate(Bundle savedInstanceState) {
apiService.loadCar()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe();
}
}

Now we want to call asynchronous task. In order to do that, we have to use subscribeOn(Schedulers.io) to execute the observable on a new thread.

If we want also to get result in main UI thread, we have to use observeOn(AndroidSchedulers.mainThread()) which means that result emits through on the main UI thread.
subscribe() method is kind of trigger. If you don’t call it the request never executes.
If you take a look closer to subscribe method you will notice that there are more overloaded methods. I prefer to use subscribe method and handle errors. I will explain this below.
Let’ modify our request and add to subscribe method parameter Subscriber.
It should look like that:

public class Activity extends AppCompactActivity {
APIService apiService;
@Override
protected void onCreate(Bundle savedInstanceState) {
apiService.loadCar()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Subscriber<Car>() {
@Override
public void onCompleted() {
}
@Override
public void onError(Throwable e) {
}
@Override
public void onNext(Car car) {

}
});
}
}

There are couple of important things. Let’s start from onNext method . That method provides you with response for loadCar request, in our example that is object Car and immediately method onComplited executes.

onNext method calls everytime unless you have kind of error, for example JSONException,IOException etc. In this case method onError called instead of onNext() and onComplited doesn’t execute.
There are couple of cases to execute onComplited and onNext instead of onError when you have error. But that is subject for next tutorial.

Example 2

Let’s see what happens when we use subscribe method without parameters . We are going to resource Observable and find couple of overloaded subscribe methods. Let’s check subscribe() method:

public final Subscription subscribe() {
Action1<T> onNext = Actions.empty();
Action1<Throwable> onError = InternalObservableUtils.ERROR_NOT_IMPLEMENTED;
Action0 onCompleted = Actions.empty();
return subscribe(new ActionSubscriber<T>(onNext, onError, onCompleted));
}

On the surface everything looks pretty nice. Above we have three Action object for each action in our request. But what is weird is static value:

InternalObservableUtils.ERROR_NOT_IMPLEMENTED.

Take a look closer, In InternalObservableUtils class found:

public static final Action1<Throwable> ERROR_NOT_IMPLEMENTED = new ErrorNotImplementedAction();

Implementation class ErrorNotImplementedAction with method call will throw exception:`OnErrorNotImplementedException`;

public void call(Throwable t) {
throw new OnErrorNotImplementedException(t);
}

Final note

So if we subscribe to observable using subsribe() (method without parameter) it will work fine. But as I wrote above, it is possible to get error which is handled by onError method. In this case you will have crash because of throwing exception OnErrorNotImplementedException.
We should handle error in our side either by implementing onError action or providing Subscribe object.

Hope you enjoyed this coding tutorial, you can expect more in the future.

What are the costs of making a mobile app

How Much Does It Cost to Make a Mobile App?

A key question on the mind of any client that approaches us with an idea for a mobile app is the cost it would take to develop one. It’s a natural question and one that has no hard answer as the cost varies on many factors. This is why we at Mood Up invest a sizable amount of time into understanding a client’s requirements and expectations of a product, preferring agile pricing over a fixed priced.

Some factors such as the ones below, however, are ones you should pay attention to

1. Your priorities

You’ve probably seen the image above before and with good reason.

If anyone tries to convince you of a possibility to have all three, hire him for your sales team and not software development.

Remember, if something sounds too good to be true, it usually is.

2. In-house or Offshore development

Building your software in-house can be cheaper than outsourcing if you have a pool of talented designers and developers waiting on standby.

This, however, is not the case for many companies, which is why they prefer to outsource software development to independent companies such as Mood Up who possess the skill sets and experience needed to meet expectations.

We at Mood Up are strong believers ofnearshoring, which provides customers with all the benefits seen with offshoring business processes and more.

3. Devices and Android or/and iOS platforms

With the numerous amount of devices that users today connect to the internet, it’s important that you decide on the platform you’d like to be on.

Not sure how to do so? Take a look at ourtips for clientswhen considering the platform for their apps.

4. App design

Apps with beautiful User Interfaces (UI) and Experience (UX) do not happen by chance. They are the result of many hours of scoping, wireframing and numerous round of designs.

As you might have guessed, higher UX and UI quality can increase costs, which is why  we pair designers and developers together to ensure a balance between cost and efficiency.

5. Features

An app that can do everything is not good for anything.

Be clear about the function you want your app to serve and stick to it.

The features you expect of your app should be made clear to the developers from the start as the planning for its development depends on it.

6. Maintenance

Building an app is not a one time task as you would think.

Its process that one must pay careful attention to, and improve based on user feedback, bug reports, security and operating system updates.

7. App testing

First impressions are important and launching an app riddled with bugs will have disastrous consequences.

Testing is paramount before launching an app, but they do not come cheap.

8. Marketing

You’d be forgiven for thinking that the costs of an app are only technical and the only thing left to do is to figure out amonetization strategy.

But how would you reap the benefits of this monetization strategy if you haven’t got any users?

Remember to integrate the cost of marketing to your app.

Conclusion

App development is not an easy task, which is why we help our clients with detailed strategies for execution. It’s important to remember that there is more to developing an app that you would see on the surface, and the costs will reflect it. The above eight factors, however, should give you an understanding of the factors you should take into consideration.

PS- never trust a developer or a software house that asks too little questions. The questions you should be asked now will make sure there are no unpleasant invoices later on.

Have an idea that we can help develop? Tell us morehereand we can get started.

Why nearshoring in Poland is a good choice

6 Reasons Why Nearshoring in Poland Is a Good Choice

Scaling a business brings a fair bit of what we like to call growing pains, requiring many considerations from the owners part. One such key consideration that we would like to highlight today is the investment one must make in a product, to ensure it creates real business value and continue to do so.

Of course, you can opt to hire a software developer or delegate it to an in-house development team if you have one. Doing so, however, might lead to lower creativity, reduced innovativeness with longer development times and higher costs.

Such recurring issues is why many clients prefer to hand over their ideas for growth to external software houses who possess the required creativity, tools and technical expertise to deliver high-quality products at lower costs.

What is nearshoring?

Nearshoring as you might have guessed is a derivative of the termoffshoringand is essentially the outsourcing of processes to companies in nearby countries. Such outsourcing of work to countries near each other is proving to be quiet popular in Europe where most nations are only a few hours of flying away.

Example- a customer in London can outsource their work to a company in Poland and make periodical visits to check on progress with a two-hour flight.

What benefits does nearshoring bring?

Nearshoring shares a few benefits with outsourcing

  1. Lower costs–  a client that opts to nearshore their work incurs lower production, research and labour costs.
  2. Access to a larger talent pool – you can hire professionals

Some advantages, however, are unique to nearshoring

  1. Same time zones– large time zone differences make regular communication difficult, leaving both parties bleary-eyed with late-night/early morning consultations. Nearshoring remedies this as the lack of large time differences reduce the need for developers to pull graveyard shifts, improving theirquality of code.
  2. Fewer cultural differences– being on the same continental region means fewer cultural differences and enhanced cooperation.
  3. Faster problem-solving– being on the same time zone or in one close to the developer provides the client with the ability to reach out and highlight any issues. The developers, in turn, can respond at the same speed, leading to faster problem-solving.
  4. Proximity– short distances allow for more frequent and less expensiveface-to-facemeetings that will definitelyboost the productivityof the collaboration. This is important to us as we take a partnership approach to our clients and require theirfull involvement, just as we send our team to client HQ.

Remember, teamwork makes the dream work!

Why choose Poland for nearshoring?

  1. Software development services arecompetitively priced.
  2. The population of Poland is larger than Scandinavian countries combined and produces over40,000 IT engineers each year.
  3. Polish engineers are considered one of themost competentin Europe when it comes to new technologies. Their skills are enhanced by Poland’s membership in the European Union and Schengen area which allows for the free exchange of labour and information.
  4. Polish culture is inherently European, ensuringa closer fit with other European clients.Poles are also very adoptive withhigh communicative skills in English,  seamlessly integrating with cultures outside Europe.
  5. Poland’s geographical location in central Europe makes itaccessiblefrom every major European citywithin 2 hours.
  6. The Polish economy shows constant growth, with high levels of trust and a low level of corruption. This stable political and economic climate makes it very conducive for business.

Conclusion

Outsourcing software development can be a nervewracking affair for some clients.  Nearshoring, however, is a very interesting and promising alternative, with Poland leading the way as a trusted powerhouse for high-quality software development.

Interested in having a conversation about how we can help build your product? Tell us more about ithere.

Why client’s full involvement is a recipe for success Pt. I

Full Client Involvement Is a Recipe for Success (Pt. I)

Creating a great app is every client’s end goal and one we can definitely help with. Successful products, however, do not happen by chance and require our clients to work with us very closely, as they are its first users.

Why we insist on this is as ourAgile development approachdepends on fast feedback from clients so that we can, in turn, focus on the coding and deliver a shippable product at the end of our sprint.

This picture is the perfect example of how we work

Why code review is so important

Why Code Reviews Are Important

One of the most important lessons we’ve learnt over time is that we are unable to provide unbiased, objective opinions of our work, let alone check it for errors. In no ways is this an admission of inferior quality of work, as we humans are liable to err due to many reasons.

This is why we as software developers need another developer of equal or higher skills to review the code produced.

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.” –Edsger Dijkstra(Dutch computer scientist, winner of the 1972 Turing Award)

The reasons for code reviews vary based on many factors, including but not limited to, the project, the client, the developers and quality assurance processes built into the development cycle. Their biggest impact, however, lies in,

  1. Teaching and knowledge sharing
  2. Ensuring coding standards
  3. Defect-free software

Other very common outcomes are security, scalability, maintainability andcomplete unit tests.

How does it work?

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan(Canadian computer scientist, co-author of “C programming language”)

Code reviews are performed by developers who played no part in its creation in order to provide objective, unbiased feedback. Such feedback is not necessarily positive as their end goal is to maintain code that is readable and clear to everyone, not only for those deeply involved in the project. Such reviewers of code usually possess a checklist to find common mistakes and validate it against the company’s coding standards.

Code reviews should take placeduring all stages of development,except for demos or experiments. This is all the more important when the project is nearing its end, as code reviews can greatly reduce the number of bugs and are essentially a developer’s insurance for the company’s coding standards. Code reviews also go a long way towards reducing the development costs as finding and fixing bugs during development will be cheaper than finding them later on.

The code review checklist looks for common mistakes and those that aretypically harder to findsuch as:

  1. Thread synchronization
  2. Error conditions
  3. Accounting for reference-counting
  4. Resource leaks
  5. Security problems

Remember, software development is a constant process that needs regular updates, which is why we place a heavy focus on code reviews to ensure the created code is clear to any developer who might read it.  They help keep the code organized and create a space for making comments which can bepriceless for another developer who might be given the job of updating the said code late on.

They also allow a developer to passtacit knowledgegathered from the initial mistakes made at the beginning of development to a developer who might be new to it.Code reviews are therefore an excellent means of transferring knowledgebetween experienced developers and rookies.

Conclusion

Code reviews help launchsuccessful products and save money. It is also a great way of transferring knowledge from senior developers who can offer their advice to juniors, whilst the juniors can help to find errors in the code. Remember, good code review practices should be integrated into any software development cycle as they are the hallmarks of a software house you can trust.

Have an idea that we can help with? Tell us more about ithere.

Powerful Designers Developers Mix

Designers + Developers = Better Products

Today’s modern product development life cycle requires designers and developers to communicate more and collaborate, a far cry from a time when they worked in their own silos and converged only at hour-long meetings.

Such an approach to work allows for a smoother and faster development cycle, as expected of all projects that function on the Agle methodology. It also allows for

#1 Instant problem solving

Problems in a software development project need to be resolved fast, as it can interfere with the velocity and delivery of the expected product at the end of a sprint. That’s why we at Mood Up pair designers and developers, as it allows for faster feedback and brainstorming solutions.

 

#2 No more backtracking

Hiccups are part and parcel of any software development project as we cannot anticipate every issue that will pop up. We could, however, reduce the probability of such issues by pairing designers and developers, who will work simultaneously.

Such pair programming allows each other to keep track of the velocity of the project, and deliver required components on time and budget as one cannot work without the other.

 

#3 Budget-friendly project

Contrary to popular beliefs, software houses do their best to produce high-quality products at the lowest possible cost for clients.

That’s why our clients love our efficient approach to development that is only possible by uniting designers and developers.

Great product with lower billable hours = happy client

 

#4 Speed up the process

As we keep reiterating, communication is essential to our velocity in product development. Faster communication help us solve problems as they arise, reduce billable hours to our clients and get back to what we do best- code.

That’s why we recommend our approach of mixing designers and developers together to all software houses.

Remember,dynamic products require dynamic solutions.

Here is what our lead designer, Dawid had to say on this

“Communication is the key for faster development. I’ve found itincredibly useful to have developers in the same room we do our designs in. It helps us to discuss progress, what needs to be done and how we can improve on current builds so that the client gets the best product possible. Such a collaborative approach allows us to accomplish a significant amount of high-quality work in short timeframes.”

We’d love to hear your opinion about our approach to pairing designers and developers together. Is it one you would try foryour project?

Why Agile is better for your product than fixed price

Is Agile Pricing Better Than Fixed Pricing for Your Product?

A product will never be perfect in a world that is as fast-paced as the one today.

Customer requirements change and the products that serve them need to evolve if they are to retain their usefulness. Many entrepreneurs, however, tend to forget this quite often and remain in pursuit of creating the perfect product, which ends up in higher development costs and missed opportunities.

At Mood Up team, we advocate a more agile approach to developing products as they allow for faster development and more updates at a lower cost for our clients than the outdated fixed priced approach.

“We don’t actually finish our films, we release them.” John Lasseter – Pixar executive

What John Lasseter said represent Agile approach pretty nicely, as there is no possible way to predict every bug, flaw, feature request of your product until the customer gets their hands on it. A successful product, therefore, is only possible if it is constantly evaluated and improved upon.

But what exactly is a successful product?

Succesfull product

A successful product in our eyes is one that satisfies its end users and help its owner achieve intended business outcomes. Such products, however, need to be fast on its feet and adjust itself to fit the evolving requirements of its users, or risk being replaced by its competitors. This makes every hour crucial, as the competitive forces that threaten to replace your product are surely using the Agile approach to develop their products, at a lower cost.

One must not, however, confuse the Agile approach with a half-baked approach to product development, as Agile products are usually released when they are at 90-95% completion, with the rest being completed via user feedback. Such early releases allow a product to leapfrog ahead of their competitors and take a co-development approach with a new ally- its users!

You might now be getting a glimpse into why we at Mood Up team tend to favour the agile approach to developing products.

Keen on learning more about the Agile approach to software development? You can read more about it in the Agile Manifesto. You can find out more here:

But how do Agile products lead to cost savings?

Software development is not an easy task, but some good brainstorming should help you decide on the platforms it should support , and it’s monetization strategy. The challenge, however, is far from over as you now have to grapple with planning, mutual understanding and uncertainty:

  • Planning: objectives tend to change over time with customer requirements, making already completed portions of the software redundant. This is a waste of time, effort and can lead to endless frustration for the product’s stakeholders.
  • Mutual understanding of needs: a good partnership is one where all parties understand each other’s needs. Failure to do so is akin to an invitation for trouble and will drain resources.
  • Uncertainty: no two projects are the same, making accurate predictions about development time and costs impossible. Attempting to do otherwise in our experience is a waste of time and money, causing frustration for all parties.

You see the pattern, right? That’s why here in Mood Up team follow Agile methodologies tospecify,design,implementandrelease iteratively.

Our approach to developing software

The unit of development we use is ‘user story’- a client expectation that will be transformed into a feature, e.g.: “As a user, I want to sort my photos by date”.

Such user stories help in understanding the client requirements and the final output that must be developed, tested and implemented. It also aids us inprioritizing tasks, as they aredeveloped with a thorough consultation with the client,allowing us to have a mutual understanding of what’s important for the client.

The agreed user stories are then handed over to the developers, who work on2-4 week work bursts called ‘Sprints’,to produce the same. At the end of each sprint is the delivery of part of the product to the client who then provides us with feedback on it as the rest of the work progresses ahead. It’s also not uncommon to release the completed portion of the product, as it has undergone thorough testing.

You might now have an understanding of how this approach to software development might alleviate the issues we saw in planning, mutual understanding and uncertainty.

Round-Up

Here’s how Agile can help you

  • Avoid bad surprisesafter months of costly development
  • Receive the features you need firstwith user-stories
  • Remain flexibleto unpredictable markets, users and objectives
  • Control development progressand intervene if development deviates from agreed upon objectives
  • Lower probabilityof conflict between clients and the development team
  • A real focus on product development over excessive documentation

Got a product we can build over Agile? Tell us more about ithereand get an estimate.

Why native apps are better choice

Why native apps are better choice?

Developing an app requires numerous things that you need to consider . When idea has emerged, you can move to planning, development process, testing and then finally you start deployment. However, there is question that you need to answer even before starting whole development journey. You need to decide how you want to create your app – whether to make it a web app or native app.

In this article you will find out what exactly are native and web apps and why here at Mood Up Labs we strongly believe that native apps are better.

 

Web vs. native – what’s the difference?

Web apps are applications that can run on desktop in web browser or can be accessed via your smartphone browser, Internet connection is required . They are created using HTML5, JavaScript and CSS. They don’t need to be downloaded onto device. They look the same on every device, no matter what OS you are using and it is easier to offer them at multiple platforms, because no special approval from app stores is required.

Native apps on the other hand are tailored for each and every device they are supposed to run onto, they are written in language that is specific to platform . They are compiled using native SDKs and run independently from a browser on mobile devices. They are more complex to develop and need to be downloaded, you can do so by choosing them from app stores, e.g. Apple’s App Store or Google Play store.

World is heading towards mobile  and the day when desktop computer will be used only by few is closer than you might think. Right now number of mobile users is bigger than desktop users.

native-apps-vs-web-apps

 

Native apps are preffered by customers

Studies show that mobile experience is crucial to brand image and the way users are interacting with it. Poorly delivered mobile experience can put off customers and right now every business should be customer-focused.  Companies that develop native app get immediate competitive advantage.

Here are reasons why at Mood Up Labs we strongly believe native apps are better choice:

#1 Native apps are offering better personalization

Personalization is the key and thanks to native apps, you can provide your users with communication based on their location, behavior, interests and other factors.

And that’s not all, personalized content can result in higher conversion rates.

#2 Notifications

E-mails so widely used and sometimes even abused by companies are no longer very effective way of communication. Open rates are dropping, not to mention click rates.

Just think about amount of e-mails you receive every single day, even if it’s not spam. There is no way that you will spend your most valuable asset – time, to read every offer you get.

Here comes push notifications and in-app notifications offered by native apps – they communicate in non-intrusive manner with your user instantly.

They can result in very good click-through rates if your notification campaign is planned carefully.

#3 Mobile device features

Native apps can take advantage of device features such as: GPS, contact list, camera, accelerometer and many others, thanks to that they might deliver interactive and entertaining UX.

While adding more and more features is not recipe for success, choosing them wisely will make your product better.

#4 Native apps work offline

One of the most basic difference between web and native apps – the latter can work offline. While majority of them need Internet connection to perform crucial tasks, they still offer content and functionalities in offline mode.

#5 Design

Web apps are dependant on browser, so address bar, ‘refresh’ and ‘back’ buttons must be taken under consideration.

Native apps don’t have that restriction so by choosing them you gain freedom in designing app with elaborate functions that can offer innovative functionalities.

apptime-flurry-native-apps

 

#6 Users preffer apps

Users are spending a lotmore time on apps than websites and it’s safe to say that amount of time will still rise. We often see people stop using desktop computer to reply to someone or check something on their smartphone, don’t we?

#7 Native apps are faster

Well-developed native app is quicker than web app and as I mentioned earlier – time is our most valuable asset.

Native apps usually store data on mobile device so they can run smoothly, they also store user’s preferences, so that UX can be much better.

Conclusion

Developing native app requires more effort and resources but in the long run it pays off . Both, native and web apps have their pros and cons but native apps offer great personalization and efficiency. Delightful user experience is the key to successful product and higher chances are you will achieve it with native app.