Category: Mobile Development

With the advent of cross-platform toolings such as React Native and Flutter, does it make sense for companies to invest in multiple native development apps on iOS and Android?

In the mobile development space, there are many going all out with Flutter and React Native. Most of them claim that it could save up to 30–35% of your time (and thus costs) by working with Flutter or React Native. Let’s analyze as to how much of this is really true, and does this apply to you?

Long Version

There are more than 100 mobile applications are developed in the past five years, many of which have gone viral, got funded, and ranked in top #10 lists. In 2010 there were Objective-C in iOS and Java with Android and transitioned to Swift and, in recent years, to Kotlin.

There were satisfied with the tooling and didn’t pick up Hybrid Apps (built on Cordova or any Web layer) as they reduced the User Experience to a great extent. AngularJS (1.x) appeared in 2015 much before v1.0 was launched and then came along React - as it matured.

With React already being used in production systems and clients want to work in React Native. In Dec 2018 - Flutter was launched!

The approach that flutter took was different from React Native, and it held a strong premise of overcoming the pitfalls that React Native (and other Cross-Platform apps had in general). Thus, It’s time to debunk some myths and establish some facts around mobile app development.

1. Your code can be 100% in React Native/Flutter Mobile applications these days can’t be an island; depending upon the product features, one will need to interface with a lot of third-party solutions to integrate within the apps - more so for cross-platform apps than native. There are different libraries for error tracking, performance monitoring to very specialized tasks such as video conferencing, and chat tools. Most of these libraries provide first-class support for Native libraries, and then, if they deem essential - create wrappers for cross platforms.
   Depending upon your approach, you will have to choose between writing parts of your applications in native code or in Flutter/React - at times, causing more pain than ease.
2. Flutter is here to stay, now and forever Huge corporations such as Google will never have a single strategy, and it has a history of knocking down projects (some even successful by many standards) if it doesn’t live up to their expectations. Also, frontend libraries and frameworks are notorious for having a short life cycle.
   In early 2016, Microsoft acquired Xamarin for $500–600 Million - and in my opinion. Microsoft dropped Xamarin like a hot potato in recent years and has instead moved its focus on Machine Learning.
   Google’s beloved AngularJS, once considered revolutionary came into existence, got a lot of fanfare, adoption; and then criticism all within a span of a few years.
   Google is simultaneously also backing Kotlin; it can create not only cross-platform native apps (like Flutter) but also can work on Web (Flutter supports it too) and backend systems too.
3. You will always save costs upwards of 30% while working with Flutter/RN Yes, there are cost and time savings when it comes to working with cross-platform apps - not just in development; but also in QA and Project Management; But these benefits are assuming that you don’t rely on too many third-party frameworks that have little to no support for your SDKs.
   There are some animation effects, gradients, and such which are not available in React Native despite it being in existence for a long time.
   So sometimes getting these to work with your apps can be a pain; but if you’re looking to build apps that aren’t heavily dependent on these services or if these SDKs form a minor portion of the app then yes; you will still save money working with Flutter/RN
4. My Flutter/RN team need not know any native development It would be foolhardy to take a beginner, not knowing any native development to work directly on Flutter/RN. If you’re starting mobile development, learn Kotlin/Swift first - get a firm grip and then move on to Flutter/RN; also to know RN, you will first need to get acquainted with React - not a short learning curve, eh.
   Again, depending on your application, you could do away with this requirement, but if you need support ;  you will have to get your hands dirty in native code or get help from other native developers on your team.

And now, time for some facts!

1. Your Flutter app will be as performant as a native app Flutter was built for performance, and our recent experience in building flutter apps has been a resounding success. We recently launched a Flutter app for the fifth-largest marine player in the world!
   The only downside you can see upfront is the size of the apps developed in Flutter; they are usually 30MB+ (though it’s not a deal-breaker for most considering increased bandwidth and internet penetration around the globe)
2. You will be able to ship apps faster While it might look to a developer at a macro level that he’s spending more time than needed; sometimes while working with React Native/Flutter as opposed to native development - they do save time overall.
   With Flutter; you’re able to ship apps quicker, which means you can pack in more features in every sprint; so everyone’s usually happy.
3. You can add Flutter to existing apps! With the launch of v1.12 of Flutter, the “add to app” functionality has finally gone mainstream; even within Solutelabs,  we have started pitching to clients about creating new features in Flutter.
   Adding Flutter to existing apps would mean that your native development team would have to reskill themselves in Flutter. This could be a deterrent factor for some teams and might not be for some.

If you already have a native iOS or Android app and don’t need many external SDKs; try adding flutter to the mix, it’s easy to learn, and there are some excellent tutorials on Flutter out there!

And if you’re starting from scratch; have a look at your app and see if it’s heavily dependent on SDKs that don’t have a Flutter/RN SDK. If not, and if you’re starting - go for Flutter.

Since the B2C expertise is superior, it’s pushing businesses to boost their B2B aspect still. With B2B customers on the move, it’s imperative for businesses to boost their mobile client expertise.

If you’re not puzzling over up your B2B uxor, you should. Your competitors are most likely finished the design and already getting rid of your customers and profits.

Steps to Get B2B Mobile UX Right:

Enhance client Satisfaction

Your business’s longevity depends on the satisfaction of your customers. Your business will solely be as sturdy as your client retention rates.

Avoid Negative Reviews

Easy Search

A B2B app normally offers expansive product catalogs, which makes robust search capabilities an essential feature. You should allow customers to go beyond the basic SKU-based searches, and search products based on price, availability, etc.

Develop a Well Thought out Navigation

Poor navigation will certainly value you, customers. Here are some ways to create higher navigation:

• Card kind will assist you to analyze your visitors’ expectations to find product or pages
• Use familiar words
• Put the pushcart within the top-right corner.
• Navigation ought to be simple enough to faucet on a mobile device (not too tiny for fingertips)
• Use breadcrumbs —your customers mustn’t feel stranded on a page with no thanks to going back to
• Navigation ought to be unbroken as consistent as attainable from page to page

Purchase History

You should give your customers access to their previous purchase information; it will facilitate them to place new orders quickly. You must additionally modify your customers to edit their orders: change quantities, dynamical shipping addresses, etc.

Personalization

Personalization is a very important tool for making a loyal client base. you can do it in the following ways:

• You can send personalized deals and offers to your customers to encourage them to stay shopping for you.

create the cargo efficient and straightforward for your customers by providing integrated and automatic shipping. Hassle-Free shipping expertise can gain you the customer’s trust and can convert them into loyal purchasers.

Source: Netsolutions

The B2B online marketplace is getting increasingly competitive; but competition is good because it pushes you to get better by trying new things, thinking up new strategies, and taking risks. Sometimes you may even come up with something that becomes a big trend. Competition forces you to sit up and take notice.

Here are 5 reasons why B2B mobile commerce is going the B2C way:

1- The rise of the mobile

It’s the age of mobile, and it’s gradually becoming the age of a mobile-first strategy in both B2B and B2C marketplaces. With the rise in mobile usage, B2C companies have already been leveraging mobile and rising in the m-commerce realm; lately, B2B companies have also started being inspired by the strong numbers B2C companies are achieving.

Mobile commerce has obviously existed in the B2C realm for much longer than it has in B2B. For mobile solutions, B2B suppliers have so far been using legacy solutions only, such as a barcode scanner, or other expensive proprietary hardware.

But in the last few years, B2B buyers have also started offering their clients a way to place orders on a mobile device, although it is relatively new for them. The suppliers going in this direction are able to seize enormous opportunities because B2B buyers are enjoying the ease and speed of order, which they experience as B2C buyers.

B2B buyers are no different than B2C buyers. Business buyers possess an on-the-go nature and this makes it necessary for them to have access to a robust app experience on their mobile devices, in addition to desktops.

Below are some statistics that show why B2B businesses are following the B2C m-commerce trends:

• 80% of B2B buyers are using mobile at work.
• 60% of B2B buyers report that mobile played a significant role in a recent purchase.
• 70% of B2B buyers increased mobile usage significantly over the past two to three years.
• 60% of B2B buyers expect to continue to increase their mobile usage.
• 50% of B2B queries today are made on smartphones. The figures are expected to grow to 70% by 2020.

2- B2C has changed the B2B buyer

The typical B2B buyer is changing; With this change in buyer behavior, businesses are also changing their sales process.

B2B buyers also expect multi-channel ordering experiences so that they can purchase from websites and mobile apps.

A millennial B2B buyer prefers the same seamless, personalized mobile experience that they have on B2C platforms as consumers.

B2C best practices that are being adopted by B2B:

• High-quality product images and videos
• Robust onsite search with visual merchandising
• Social proof in the form of reviews and ratings
• Flexible shipping options and order updates
• Personalization based on past purchases
• Meant-for-mobile storefronts
• Online catalogs for easy browsing
• Real-time product and stock availability
• Customer service via chat and phone support

Mobile can fast-track time to purchase by 20% through facilitating efficiencies in decision-making and enhanced team collaboration, particularly with more complex purchases.

Millennials spend more than six hours a day on their phones, twice the time spent by people over 45 years old.

With the right platform, B2B companies can completely transform the way they do business and drive more long-term sales.

3- B2B buyers open to new opportunities

B2B merchants are adjusting their business models to accommodate m-commerce/e-commerce because it’s the need of the hour.

It cannot be mentioned enough that B2B buyers are the same people who make purchases as consumers. It’s a simple truth that cannot be overlooked anymore.

As people have increasingly started shopping online, they have become accustomed to a certain level of the online experience. Those expectations are still there when they put on their “B2B buyer’s hat.

The stats below show that B2B merchants are incorporating online selling into their business:

1. 78% of survey respondents that sell online have done so for at least two years.
2. 41% of B2B retailers expect B2B online sales to grow more than 25% in 2018.
3. Payment options are a vital part of the B2B e-commerce sales process.

The rise of mobile apps and marketplaces like Amazon clearly shows that B2B retailers are quickly moving from early experimentation with m-commerce/e-commerce channels to full-fledged omnichannel sales approaches.

In short, B2B retailers are no longer novices in the online selling process.

4- An improved B2B CX leads to new customer acquisitions

B2C companies are using a variety of acquisition channels; therefore, B2B merchants are doing the same. The good thing for B2B is that everything has been tried and tested by B2C companies and all they have to do is pick the things from B2C that will fit into their B2B business.

A few of the businesses that had websites were more of portals and they only served as online catalogs. The idea was not to replace customer service reps with online technology. Only the existing customers were served, which means, no online strategy for new customer acquisition.

Social media also plays an important role in bringing in new customers, which again highlights the shift in B2B buyers’ behavior as it moves toward a more B2C-behavior path.

5- The success of other B2B online sellers

Grainger is a Fortune 500 industrial supply company and it perfectly exemplifies the emerging overlap of B2C and B2B. Once logged into their account, buyers are navigated to a homepage that mirrors any popular B2C site. Similarly, their product pages also bear all the major B2C hallmarks.

There are many B2B merchants who are leading the way for others, who are still new to this mirroring of B2C UX, or who are in the e-commerce development stage. But it is evident from all the above points that B2B is benefiting a lot by becoming more like B2C.

Source: BCG, 2017

These are practical, straightforward steps that developers can take, with code examples, links to Secure Software. Consider this article a sneak peek at the latest OWASP Top 10 list for developers. If you have questions or suggestions, we’d be happy to hear from you, Just send an email to  info@apptech.com.tr.

1. Protect Your Database From SQL Injection

One of the most dangerous (and most common) attacks on web applications is SQL Injection: attackers inserting malicious SQL into a dynamic SQL statement. SQL injection vulnerabilities are easy for an attacker to find and exploit using free tools like SQL Map or SQL Ninja, or even manually: try inserting a value like 1′ or ‘1’ = ‘1into the user name, password, or any other text fields and see what happens. Once SQL injection vulnerabilities are found, they’re easy to exploit.

Luckily, SQL injection is also easy to prevent. You simply need to parameterize your SQL statements, making it clear to the SQL interpreter which parts of a SQL statement make up the command and which parts are data. OWASP has a Cheat Sheet that explains how to parameterize queries in Java (using prepared statements or Hibernate) and in other languages.

2. Encode Data Before Using It

SQL injection is only one type of injection attack. Stopping SQL injection is easy. Stopping other kinds of injection attacks—LDAP injection, XML injection, XPath injection, OS Command Injection, and especially JavaScript injection (aka Cross-Site Scripting)—takes a lot more work.

The solution to injection attacks is simple in concept: if you can’t clearly separate code from data (which is what you do to prevent SQL injection using a parameterized API), you have to make the data safe before handing it off to an external interpreter, such as an XML parser, an OS command shell, or a browser.

To do this you need to output encode/escape data before handing it to the interpreter so that the interpreter will not recognize executable statements in the data.

3. Validate Input Data Before You Use It or Store It

All data from outside your program or service, especially data from remote clients, is evil and needs to be validated: files, parameters, HTTP headers, cookies, … It doesn’t matter if the client or the other system validated the data. You need to validate it again.

The basic rules of data validation are as follows:

• Don’t rely on client-side checking. Always check on the server.
• Use positive, whitelist validation rules wherever possible. Negative, blacklist checks that reject data if they contain dangerous or illegal values can be subverted through (double) encoding and other evasion tricks. Where you can, use strong whitelist rules that specify the size and range of acceptable values using regular expressions. Look to libraries like the Apache Commons Validator for help in how to properly check for data types like dates, currencies, IP addresses, URLs, and credit card numbers.

4. Access Control—Deny by Default

Deciding who needs what access to which data and to which features—and how these rules will be enforced—should be carefully thought through upfront in design. It’s a pain to retrofit access control later without making mistakes.

• Implement access control rules in a central, server-side management library, instead of sprinkling these rules throughout the business logic. This makes it much easier to audit and update the rules. Use the access control functions of your application framework, or use a security library like Apache Shiro to do this.
• Only use server-side trusted data (data that has been properly validated) to make access control decisions.
• Deny by default—all functions should check to make sure that the user is authorized before proceeding.

5. Establish Identity Upfront

Building your bulletproof authentication and session management scheme isn’t easy. There are lots of places to make mistakes, which is why “Broken Authentication and Session Management” is #2 on the OWASP Top 10 list of serious application security problems. If your application framework doesn’t take care of this properly for you, then look at a library like Apache Shiro to provide functions for authentication and secure session management.

Try to enforce multi-factor authentication if you can. If you have to rely on just User IDs and passwords, make sure to follow rules for password length and complexity. If you are using an email address as the User ID, be careful to keep it safe: bad guys will try to harvest email addresses for other purposes.

When storing passwords, you can’t get away with just salting and hashing the value anymore. OWASP’s Password Storage Cheat Sheet explains what you need to do and what algorithms to use.

6. Protect Data and Privacy

Protecting data and privacy is about access control (which we’ve already talked about), auditing (which we’ll cover under logging), and encryption: encrypting data in transit, at rest, and during processing.

For web apps and mobile apps, encrypting data in transit means using SSL/TLS.  Using SSL isn’t hard. Making sure that it is set up and used correctly takes more work. OWASP’s Transport Layer Protection Cheat Sheet explains how SSL and TLS work and rules that you should follow. The Cheat Sheet on Certificate Pinning explains how you can prevent man-in-the-middle attacks when using SSL/TLS.

The most common mistakes in encrypting data at rest are:

• Forgetting to encrypt data in the first place
• Trying to roll your encryption algorithm
• Mishandling keys or other setup steps for standard encryption libraries

OWASP has another Cheat Sheet on Cryptographic Storage which covers the different crypto algorithms that you should use and when. Libraries like Google KeyCzar or Jasypt will take care of the implementation details for you.

7. Logging and Intrusion Detection

Logging is important for more than troubleshooting and debugging. It is also critical for activity auditing, intrusion detection (telling Ops when the system is being hacked), and forensics (figuring out what happened after the system was hacked). You should take all of this into account in your logging strategy.

Watch out for Log Forging attacks where bad guys inject delimiters like extra CRLF sequences into text fields which they know will be logged to try to cover their tracks or inject JavaScript into data which will trigger an XSS attack when the log entry is displayed in a browser-based log viewer.

Review code for correct logging practices and test the logging code to make sure that it works. OWASP’s Logging Cheat Sheet provides more guidelines on how to do logging right, and what to watch out for.

8. Don’t Roll Your Own Security Code

Know your tools and use them. There are lots of built-in security features in frameworks like Spring Security, Ruby on Rails, .NET, AngularJS, and Play, along with iOS and Android mobile platforms that will take care of common security problems for you, if you use them right. Take the time to understand and use them properly.

9. Handle Errors and Exceptions Correctly

Error Handling isn’t sexy, but it has to be done right. Mistakes in error handling and exception handling lead to different kinds of common and serious security vulnerabilities:

• Leaking information that attackers can use to penetrate your system. Stack traces and detailed error messages can disclose too much technical information about your run-time environment or architecture. For example, “invalid user” or “invalid password” instead of “invalid logon” helps bad guys as much as it helps users.
• Missing or inconsistent error handling can lead to errors going unnoticed, unpredictable behavior, or crashes. A University of Toronto study found that small mistakes in error handling can lead to catastrophic system failures in large systems.

10. Build Security Testing Into Development

Make sure that you have good automated unit and integration test coverage for security features and controls (like authentication, access control, and auditing) and critical business features: code that handles money, private data, trade secrets, and admin functions. This has to include both positive and negative tests.

Other system-level security tests and checks can be automated in CI/CD using tools like Gauntlet, BDD-Security, and Zapper (a Jenkins wrapper over the OWASP Zed Attack Proxy). These tools make it easy to run security tests and provide clear pass/fail feedback.

It’s your code. It’s your job to make sure that it is safe and secure.

It’s essential for developers to include app security in their development plans. Here are several different ways to build a secure mobile application.

First comes the app concept–that’s the easy part. After the stroke of inspiration comes a lot of planning, outlining, and strategizing to make that app dream become reality.

There are a lot of factors that go into app development, and in a world where hacking, data leaks, and cybercrime is more prolific than ever security needs to be at the top of the list when starting a new project.

The last thing any app developer wants is their idea to go bust because of a major security flaw. With proper security planning and strategy, it doesn’t need to, though. Here are 10 tips to ensure your mobile app hits the ground securely.

1. Incorporate the security team from day one

Security should be part of the mobile development process from the first time the dev team sits down together. Whether you’re SWOTting, Scrumming, using DevOps, Rapid, or Agile it makes no difference: Include security so every change incorporates it.

When a change is made or a major revision is planned, always consult the security team so they know how to account for any issues that may arise.

2. Test, test, and retest

As reported on TechRepublic last year, 60% of developers lack confidence in the security of their code, yet don’t take steps to fix it. The problem, as NodeSource and Sqreen mentioned in their report, is partially due to testing–lots of developers just aren’t doing it.

QA is an important part of building secure code, and like security as a general concept, it shouldn’t simply be tacked on to the end of the process. Review code constantly and identify every potential security hole you can find, then fix it before it ends up live.

The biggest concern that developers have, according to the report mentioned above, isn’t actually due to lack of testing: It’s due to something else entirely, particularly the problems inherent in third-party dependencies.

3. Don’t assume the safety of third-party dependencies

It’s common for developers to incorporate portions of code available free or for sale from other sources: Why reinvent the wheel when it already works fine as-is?

Third-party code isn’t always safe, and according to the NodeSource/Sqreen survey cited above, only 16% of developers trust the third-party dependencies they use. 40% skip review for those third-party components, though.

Don’t be one of those programmers. Thoroughly pick apart your third-party modules to be sure they’re safe.

4. Careful with that API

APIs are an essential part of backend programming, but they’re also a security headache since they often need to face the outside world. Be sure that the APIs you’re using are verified for the platform you’re developing on.

Be sure to also incorporate an API gateway as discussed in this TechRepublic piece.

5. Think like an attacker

When you’re writing code, think about it as an attacker: Could you exploit this? What may seem like a minor issue not worth addressing could be a vulnerability a hacker could use to attack your application.

Code reviews should always include some time spent looking for ways to break the app. Don’t stop at obvious flaws either, some attacks are so inconceivable that you should be testing, and accounting for everything. That goes double for mobile devices, which are subject to a wide variety of environmental variables.

6. Eliminate attack vectors by minimizing permissions

Zero-trust security is one of the fastest-growing security methods, and with good reason: It assumes no one, and nothing, on a network, is secure. As such, only the barest permissions are granted to a user or a machine, and only as needed.

Your mobile app should be designed in the same way. If it doesn’t need access to the camera, or contacts, or the dialer, don’t ask for it. If it doesn’t need a constant connection, don’t program it with one.

Each permission an app need is another connection it has. The best-fortified castles only have a single entrance–think of your app like a castle and eliminate all those secret exits and hidden passageways.

7. Be mindful of what’s being stored on a device

Personal data stored by an app is ripe for the plucking–get rid of it, or move it to a secure location on the device. If you have to store sensitive or personally identifiable information on a user’s device, encrypt it.

If sensitive data is used by your app there’s going to have to be a compromise somewhere: Either it’s going to be on-device or on your servers, and both are a risk. As part of developing your app, take time to determine the best place for user data, both for the user’s sake and from a security standpoint.

8. Secure data transmission

VPNs, SSL, and TLS can all help secure data in transit, as can encrypting it between the sender and the receiver. Find a way to ensure your app is transmitting and receiving data securely so it can’t be intercepted or spoofed.

9. Use tokens to handle sessions

Tokens are the de facto way to handle user logins in the modern app world, and you should use them to better manage user sessions. Not only can they be easily revoked to ensure user security, but they’re also more user-friendly, which is always a plus for an app.

OAuth2, JSON Web Tokens, and OpenID Connect are all great methods for securing and simplifying, user logins.

10. Implement tamper protection

More of a problem for Android apps, which are easily decompiled, tamper protection is a must-have for security. Copycat apps have appeared in Google Play and fooled millions of users, and you don’t want your app to be one of them.

There are a number of different ways to tamper-protect an Android app, so implement one of them, or preferably more, to protect your users and your reputation as a trustworthy app choice.

Source: Ttechrepublic