In my experience with various mobile projects, the challenge of managing too many partners in a venture often arises. This typically involves different entities handling distinct aspects such as content creation, software development, sales and marketing.

There are two critical issues. Firstly, dividing profits sensibly among all parties becomes challenging. Secondly, managing requirements and implementing changes becomes cumbersome due to excessive communication needs, overshadowing actual project execution.

Resource allocation is another area where complexities emerge. Each partner may prioritise different project facets, leading to inefficiencies and disputes over the allocation of finances, time and personnel.

It’s common for one or more parties to forego profits, perhaps as a trial or for a limited period. However, this approach is flawed because without tangible benefits, partners may withdraw, risking project collapse.

Too many partners often dilutes the project’s direction. With everyone (and no one) responsible for requirements, misunderstandings occur, issues may be overlooked and projects can falter for preventable reasons. Moreover, with multiple stakeholders, intellectual property rights issues become intricate, leading to disputes over ownership and usage rights.

Should a partner decide to exit the project or if a dissolution of partnership is needed, the presence of numerous partners complicates the division of assets, intellectual property and responsibilities.

To mitigate these issues, it’s advisable to limit the number of partners. Opting for upfront payments rather than revenue sharing can simplify financial arrangements. Engaging partners willing to contribute without immediate financial gain should only be considered if they derive other benefits, such as publicity or customer sharing for other products.

If a project must involve several parties, ensuring one entity retains overall control is crucial. Implementing processes that facilitate swift decision-making and minimise the need for extensive cross-party meetings is essential. Establishing a clear procedure for partner withdrawal is also important, as is having backup suppliers or partners to reduce the risk of project disruption.

While business partnerships can bring valuable resources, expertise and networks to a mobile project, navigating the associated challenges is critical for success.

In recent years, there has been a significant shift towards mobile devices, fundamentally altering how products and services are designed and delivered. The concepts of ‘mobile first’ and ‘mobile native’ have emerged as pivotal strategies in this evolving ecosystem, each with its own set of principles and implications for businesses and developers. Here, I explain more.

The mobile first approach prioritises the creation of websites and applications for mobile devices over desktop or laptop versions. This strategy acknowledges the increasing prevalence of smartphones as the primary means of internet access and interaction with digital content. It encompasses not only the aesthetic aspects of web design but extends to the entirety of the customer journey, including discovery, engagement, conversion and support. The rise of mobile first can be traced back to significant milestones such as the moment in 2012 when smartphone sales surpassed those of PCs and in 2016 when mobile Internet usage outstripped desktop usage.

Implementing a mobile-first strategy involves adopting Responsive Web Design (RWD), which ensures that web content fluidly adapts to various screen sizes and resolutions. Moreover, smartphone apps are usually developed to enhance the user experience further, providing functionalities and efficiencies that mobile websites alone might not offer. It’s important to realise that this encompasses every facet of the customer journey, from the initial discovery of a product or service through to post-purchase support and engagement.

Adopting a mobile-first approach is not without its challenges and costs. The development process can be more complex and expensive than traditional web design due to the need for responsive functionality and the development of standalone applications. Additionally, businesses must contend with lower conversion rates on mobile devices, attributed to smaller screen sizes and the often fragmented attention of users. One strategy to mitigate this issue is to include features that allow users to save information for later review on larger screens or when they have more time.

Despite its advantages, mobile first is not universally applicable. Many B2B sectors, for example, continue to see higher usage rates on desktop and laptop computers, where users are typically stationary and able to engage more deeply with content. In these cases, a hybrid approach that applies mobile-first principles primarily at the early stages of the customer journey can be more effective.

Progressing beyond mobile first, the concept of ‘mobile native’ represents a more radical departure from traditional digital service delivery. Mobile native services are designed exclusively for modern smartphones, foregoing use on desktops, laptops and older mobile devices. This approach leverages the advanced capabilities of today’s smartphones, such as powerful processors, high-resolution cameras, and an array of sensors, to offer unique, context-aware services that would be challenging, if not impossible, to replicate on traditional computing platforms.

Mobile native excels in engaging younger demographics, such as millennials, who have grown up in a predominantly mobile device world. This involves simplifying business processes and offerings to fit the constraints and advantages of mobile platforms, enhancing value through the unique features of smartphones.

Mobile native apps can offer immediate service access, integrated communication tools, such as Intercom, and utilise device capabilities like cameras and sensors for innovative functionalities such as automatic id checking using services such as microBlink. However, despite attempts at simplifying processes, I have found that mobile native apps usually have many more screens that are costly to implement, especially when this has to be done on both iOS and Android.

The decision to go mobile native is not without its considerations. Exclusively targeting mobile users can purposely and inadvertently exclude certain segments of the population due to factors such as device compatibility, internet accessibility, and socio-economic barriers. Thus, businesses must carefully assess the risks and ethical implications of potentially excluding some users from their services.

What initially appears as a straightforward task of creating a new mobile app, often unfolds into a complex web of challenges. The journey from concept to deployment is fraught with ‘unknown unknowns’, leading projects to extend beyond their anticipated timelines and budgets. Here, I look into the real nature of mobile development, aiming to shed light on common pitfalls and offer insights to steer projects towards success with minimal rework and less risk of cost overrun.

There are generally two classes of challenges that tend to cause setbacks, overlooked technical details at a lower level and broader high level issues that only emerge at a later stage.

Low Level Nuances

The main technical sources of complexity in mobile development stem from the inherent diversity of ‘real life’ including:

Time zones – When developing mobile applications that will be used internationally, it’s crucial to support multiple time zones. This means that the application should display the correct local time, considering the user’s current time zone. Daylight Saving Time adds another layer of complexity. This involves detecting the User’s Time Zone, automatically adjusting for DST and correctly scheduling things across zones. A best practice in mobile development is to use Coordinated Universal Time (UTC) for storing dates and times and converting to the local time zone only when displaying times to the user.

Languages – Catering for multiple languages in mobile development, known localisation, is crucial for creating apps that provide a seamless and inclusive user experience to a global audience. It’s best practice to separate code and content so that it can be easily translated during development or in the future. Some languages, such as Arabic and Hebrew, are read from right to left. Internationalisation includes supporting RTL text directions in the app’s layout and ensuring that user interface elements adjust accordingly. Beyond translation, localisation may require adapting content to fit cultural norms and expectations, such as changing images, colours and content to be culturally appropriate. Apps can automatically detect the device’s language settings and display content in the corresponding language. However, it’s also a good practice to allow users to manually select their preferred language from within the app, overriding the default device settings.

Locales – Dates, times, currencies and numbers should be formatted according to the local conventions of the user’s language or region. This includes using the correct currency symbols, decimal separators and calendar formats.

Encoding schemes for data – Encoding schemes determine how characters and information are represented digitally in software applications. Since mobile apps often interact with different systems, APIs, and databases that might use various encoding formats, developers need to ensure seamless and accurate data handling and representation. For example, UTF-8 is widely used for its ability to represent any character in the Unicode standard, making it a popular choice for mobile applications that need to support multiple languages. However, other systems or legacy data might use encoding such as ASCII, ISO 8859-1, or even country-specific standards. Incorrect handling of encoding can lead to data corruption, where characters are displayed as garbled text or question marks.

Currencies and preferred ways of paying across countries – This is especially important for applications that handle transactions, e-commerce or any form of financial exchange. It’s important to provide convenience and familiarity and also ensure compliance with local regulations and financial practices. Think about dynamic currency conversion, localisation of pricing and nuances of different currency formatting and rounding. Integrate with the expected local payment systems and comply with regulations such as GDPR in Europe and PCI DSS for payment card security.

Multiple network operators, country codes and phone number formats – Care needs to be taken especially for applications that involve communication, authentication, or any form of data exchange tied to the user’s phone number. Phone numbers vary significantly in format across different countries, including variations in length, grouping and the use of area codes. Mobile applications need validate and format phone numbers for storage and internal use, while also displaying them in a locally familiar and readable format to the user.

Multiple input types – Catering for multiple input types in mobile development is essential to ensure that applications are accessible and provide a seamless user experience across various devices with different input capabilities. Users will be accessing apps from devices that range from smartphones and tablets to wearables and hybrid devices. These devices may support touch, stylus, keyboard, mouse, voice input or even gestures and motion sensors as input methods. Ensuring that your application is accessible to all users, including those with disabilities, is not only an ethical consideration but also expands your app’s reach.

Beyond the above technical considerations, several operational challenges often emerge:

Handling changes in SIM cards. This is a critical aspect, particularly for applications that rely on network connectivity or use the telephone number as part of the user’s identity or for authentication purposes. A new SIM card, especially when traveling internationally, may result in data roaming, leading to higher data costs for the user. Apps should be sensitive to these scenarios to avoid causing unexpected charges. Android and iOS offer APIs to detect changes in the SIM card status. Provide a straightforward process for users to update their telephone number or other relevant details within the app.

Managing high data costs associated with roaming. Users may not always be aware of the increased costs associated with data roaming or may forget to disable data usage for certain apps, leading to unexpectedly high charges. Both Android and iOS platforms offer APIs that allow apps to check the network status and determine if the device is currently roaming. Provide users with options to control data usage while roaming.

Ensuring data integrity during updates or when the device encounters storage limitations. Proper data management ensures that the app functions as intended, even when storage is low or during the update process. Use atomic operations for data updates, ensuring that any change to the data store is completed entirely or not at all. This approach prevents partial updates that could leave data in an inconsistent state. Carefully script and test data migrations between app versions. Ensure that these scripts account for various starting states, especially if users might be updating from several versions back. Implement mechanisms to backup user data before starting the update process. Provide options for data recovery in case the update fails or corrupts data. Notify users when storage space is low and could impact the app’s functionality.

Adapting to users’ changing registration details or service opt-outs. As users interact with mobile applications, their preferences, personal information, and consent to receive communications or services can change over time. Design user profiles in your application to be easily updatable. Provide intuitive interfaces for users to modify their personal information, preferences and consent statuses directly within the app. Ensure that changes to user profiles are reflected in real-time across all systems and services. This requires a robust backend architecture that can propagate updates immediately to avoid discrepancies.

Higher Level Problems

The financial planning for mobile development projects frequently underestimates the true cost, focusing narrowly on the initial development phase. However, the lifecycle of a project often involves re-work, especially as it is near or shortly after completion and new requirements emerge. This phase of refinement, while necessary, can significantly inflate costs if not managed judiciously. Plan in some financial and development contingency.

The role of experience cannot be overstated. Projects often falter when handed over to developers who promise everything but under-deliver, necessitating costly overhauls or restarts. Choosing a reputable, rather than the cheapest, developer from the outset is crucial to mitigating these risks.

Support and maintenance represents another often-overlooked aspect. All software development encounters issues, whether due to bugs or user misunderstandings. Incorporating comprehensive diagnostics and logging from the early stages can significantly reduce support costs down the line.

Lastly, new devices are often released with updated operating systems, enhanced hardware capabilities, different screen sizes and novel features. Users expect apps to work flawlessly on their devices, regardless of whether they are using the latest model or an older version. Failing to support new smartphones can lead to negative user experiences, including app crashes, poor performance and compatibility issues. You should periodically test apps on the latest devices and operating systems to identify and address any compatibility issues.

In summary, real-world mobile development is a complex field that demands a thorough understanding of both technical and operational challenges. By recognising and planning for these complexities from the outset, developers and project managers can navigate this intricate landscape more effectively, leading to successful, cost-efficient projects with fewer surprises.

Mobile startups, with their agility and innovative mindset, often find themselves on the radar of established large companies looking to inject fresh ideas and technologies into their operations. This is where the metaphor of ‘catching a whale’ comes into play, a term used in sales to describe the moment a startup catches the interest of a large enterprise. However, I have found the excitement that comes with this opportunity can quickly turn to dismay as the complex reality of engaging with a large corporate becomes apparent.

The need for collaboration between startups and established enterprises cannot be overstated. Startups operate with a speed and flexibility that large companies often cannot match, primarily because these enterprises are optimised for growing profits and optimising existing products and services. Their structures are typically not designed to foster innovation, with slow internal processes and employee reward systems that often do not encourage it. For enterprises, the easiest route to innovation often lies in partnering with or acquiring startups, which offer fresh perspectives and rapid development cycles.

Conversely, for startups, the appeal of working with a large enterprise extends beyond the substantial financial gains. Such collaborations provide invaluable product validation and enhance their reputation in the market. However, bridging the gap between the quick-moving nature of startups and the slow pace of large enterprises is fraught with challenges.

Several real-world problems can arise when attempting to forge these business relationships. Enterprises often operate by committee, making the sales process lengthy and complex as approval is needed from multiple levels within the organisation. Startups may find themselves having to submit to rigorous requests for information, drafting extensive proposals and navigating the enterprises’ ambitious public policies and strict purchasing practices that seek to lower costs and extend payment terms. Furthermore, the requirement to conform to legacy purchasing systems and the demand for compliance with various policies, including health and safety, security and anti-bribery, can be onerous and sometimes impractical for a small startup.

The problems can also be technical. Startups often use cutting-edge technologies with their mobile app development, which may not be fully compatible with the legacy systems of an established enterprise. This discrepancy can lead to significant technical challenges and delays in integration. Large enterprises typically have stringent security protocols and compliance requirements, such as GDPR in Europe, HIPAA in the healthcare industry in the United States or other data protection laws. Startups, while nimble, may find it challenging to meet these rigorous standards without substantial adjustments to their app design and data handling practices.

A mobile app developed by a startup might work well on a small scale but may struggle to handle the increased load and demands of a large enterprise’s customer base. Startups focus on innovation, rapid growth and user engagement, while enterprises might prioritise stability, scalability and integration with existing workflows. These differing objectives can lead to misaligned expectations about the app’s development, features, and rollout strategy.

Startups often embrace agile and iterative development, expecting to pivot based on user feedback and evolving market trends. In contrast, enterprises may prefer to work with fixed roadmaps and schedules, which can restrict the flexibility startups need to innovate and refine their mobile apps. Startups may allocate their limited resources across multiple projects to maximise growth opportunities. In contrast, enterprises might expect dedicated teams and resources focused solely on their project, leading to conflicts over prioritisation and resource allocation.

To address these challenges, startups must approach potential collaborations with a plan. This includes conducting thorough prequalification to understand the enterprise’s needs and intentions, perhaps favouring work with accelerators, incubators, or innovation teams within the enterprise that can move more quickly. Ensure your policies such as QA, modern slavery, health & safety and anti-bribery are in order and readily available, ideally via a link on your web site. An initial, small-scale project can often serve as a test to gauge the enterprise’s flexibility/commitment and facilitate trust for a smoother, more productive collaboration.

Enterprises, on their part, can do much to streamline the process. Establishing dedicated innovation teams or entities, simplifying funding and purchasing processes and actively promoting and supporting internal innovation can mitigate many of the obstacles facing startups. Such measures not only benefit the startups but also enhance the enterprise’s ability to innovate and stay competitive.

In summary, while the prospect of startups and enterprises collaborating holds great promise, it is not without its challenges. Both parties must enter these relationships with open eyes, prepared to navigate the complexities of blending different cultures, speeds of operation and expectations.

When starting Android development, the vast diversity of devices can initially appear overwhelming. Android has a large number of manufacturers, each with their own range of devices spanning various versions of Android, often further customised with manufacturer-specific amendments. This fragmentation presents a unique set of challenges for mobile startups, especially those without the luxury of extensive funding to test on the widest array of devices.

However, there are several strategies developers can employ to manage and mitigate the effects of fragmentation in their projects.

Embrace Standard Android Controls

One of the most effective approaches is to avoid the temptation of heavily branding apps and instead leverage the default Android screen controls. These controls are designed to be flexible and automatically scale across different devices, significantly reducing the development overhead associated with creating interfaces. You can creatively re-purpose and re-colour these controls to achieve a branded look and feel without sacrificing compatibility and scalability.

Design Specifically for Android

Designing with Android in mind, rather than attempting to replicate iOS idioms, also significantly reduces compatibility issues and lower development cost. This includes focusing on responsive and adaptive UI designs that use relative and constraint layouts to ensure your app’s interface adjusts seamlessly to different screen sizes and resolutions.

Use Compatibility Libraries

Android’s compatibility libraries, such as AndroidX, play a crucial role in bridging the gap between new and old versions of the OS. These libraries allow developers to use features introduced in newer versions of Android while maintaining backward compatibility with older devices.

Understand Your Audience

It’s crucial to analyse the devices predominantly used in your target geographic region or intended market. Often, testing on a select 20% of devices can cover up to 80% of your target audience. This approach enables you to focus their testing efforts more efficiently, ensuring that the majority of users experience the app as intended.

Simplify and Re-use

Aiming for simplicity in app design and functionality can greatly reduce the fragmentation challenges. Deep integration with the OS can lead to many more, non-UI, compatibility issues across different devices. Therefore, developers should evaluate whether certain deep API uses are essential or if there are simpler approaches. Additionally, leveraging open source libraries can save time and effort by re-using solutions that have already addressed common fragmentation issues.

Embrace Automated Testing

Automated testing frameworks and services, such as Spoon and Firebase Test Lab, enable testing across a wide range of devices simultaneously. This not only improves efficiency but also helps identify device-specific issues that might not be evident in emulator testing.

Feature Toggles and Gradual Rollouts

Implementing feature toggles allows developers to enable or disable app features for specific devices or Android versions dynamically. This strategy is particularly useful for introducing new features to a subset of users or rolling back problematic features without needing to deploy new app versions.

Seek Vertical Business to Business Opportunities

Entrepreneurs can look for niche markets or verticals that may only require support for a limited range of devices. In certain business scenarios, it may even be feasible to standardise on a single device model, which can simplify development and ensure the chosen devices are adequately rugged for the intended use case.

Conclusion

The challenge of Android fragmentation, while real, is often exaggerated. With careful planning, strategic decision-making, and the use of available tools and libraries, developers can navigate the fragmented Android landscape effectively. It’s about being prepared, adaptable, and open to leveraging the ecosystem’s strengths to create engaging and widely accessible applications. Accepting that a small percentage of issues will arise on any platform, and planning for this eventuality, can help maintain focus on delivering quality user experiences across the broad spectrum of Android devices.

When I look at past mobile startup projects, the inclusion of a domain expert within the team is most often an ingredient for success. This necessity stems from the crucial role that domain experts play in understanding potential customers, reviewing output and innovating the sales channel.

For instance, a health startup would greatly benefit from the insights of a doctor or medical consultant, while a food startup could leverage the expertise of a nutritionist to tailor its offering. Similarly, a mobile application designed to enhance visitor experiences would do well to incorporate the perspectives of someone with a background in hospitality. Enlisting the services of such experts does not necessarily require a full-time commitment. Part-time advisors can provide valuable insights without the need for a significant financial outlay.

Understanding Your Potential Customers

The core of any successful mobile startup is a deep understanding of its potential customers. This involves not only identifying the goals of the business and the expected customer base but also understanding where these customers spend their time, both online and offline, what challenges they are looking to solve and what drives them. A domain expert, with their nuanced understanding of the field, can offer invaluable insights into the minds of potential customers, ensuring that the startup’s offerings are best tailored to meet their needs.

Reviewing Output

Domain experts also play a critical role in reviewing the startup’s output, acting as stakeholders who can assess potential app features and their implementation. Their expertise allows them to identify possible pitfalls before the product reaches the hands of end users, thereby streamlining the development process and reducing the likelihood of costly mistakes.

Innovating the Sales Channel

Perhaps the most crucial area where domain experts contribute is in the development of the sales channel. It is a common misconception among startups that a superior product or service will naturally find its way into the hands of customers.

Without a robust sales channel, even the most innovative offerings can fail to reach their target audience. Domain experts can aid in this regard through their existing contacts, by training the sales team, identifying emerging trends, creating targeted sales materials and lending an air of credibility to partnerships. Their involvement ensures that the startup’s efforts in product development are matched by an equally innovative approach to reaching and engaging potential customers.

In conclusion, the role of the domain expert in mobile startups cannot be overstated. By providing deep insights into customer behaviour, helping to refine product offerings and guiding the development of effective sales strategies, these experts are indispensable to the success of a mobile startup.

I have lost count of the number of mobile startups I have visited where they have Lean Startup by Eric Ries on the table or bookshelf. The truth of the matter is that the book isn’t that accessible. Many people read it and don’t really know where to start. Others, who persevere, sometimes apply the techniques when they aren’t suitable.

In this article I take a look at the Lean Startup method, give some pointers where to start, identify limitations and provide some tips specific to mobile development.

The Lean Startup Method

The Lean Startup Method was devised by Steve Blank and Eric Ries as a way to create a new business by repeating build | measure | learn while identifying risks and testing assumptions. You document your plan, identify the risky areas and create lean experiments to exercise and evolve the plan.

From Common Agile isn’t For Startups

Steve Blank provides a great introduction in his post on Why the Lean Start-Up Changes Everything. He explains how to replace elaborate planning with experimentation, intuition and customer feedback. The emphasis is on iterative design instead of large up front development.

The above post and the book provide lots of theory but unfortunately few action points. A better place is get started is the much more pragmatic and actionable Running Lean authored Ash Maurya that’s part of the Lean series by Eric Ries – author of the original book. Ash took Business Model Generation and developed a Lean Canvas.

Limitations of the Lean Startup Method

Lean, or any method for that matter, is never the best way for every project. You will regularly read that some methodology or programming language is the best and only way. The problem is that inexperienced people read this, believe it and projects projects go astray by design. It’s necessary to look deeply at methodologies and your project and determine if there’s a match.

Here, I cover some limitations of Lean. This is not to attack Lean but so that you can determine if it’s suitable for your startup.

Availability of VC Funding

The origins of Lean came about after the 2000 recession when VC funding was sparse and new businesses needed to preserve what little capital they had while surviving as long as possible.

Most, but not all, VC funds don’t like the idea of Lean because it goes against their goals of scaling very quickly.

Every start-up is in a furious race against time. The start-up must find the product-market fit that leads to a great business and substantially take the market before running out of cash

BEN HOROWITZ, CO-FOUNDER AND GENERAL PARTNER, ANDREESSEN

Startups are inherently designed to face a high rate of failure, as the few that succeed often achieve remarkable success. In contrast, the lack of a fit between product and market typically leads to expected failure. Since considerable funds and commitment are poured into initial ideas, companies aren’t anticipated to carelessly refine early concepts. When a surplus of venture capital available, it often seems more rational to make significant, swift investments, accepting the risk of failure, rather than taking time to adjust for a better product-market fit. The primary goal is to be the first to excel and dominate the market, regardless of the expense.

However, there are a few important things to consider. Firstly, venture capital isn’t necessarily the best or chosen path for every startup. Secondly, venture capital isn’t always readily available. Finally, it’s possible to seek venture capital funding after employing Lean methodologies to confirm the suitability of your product in the market.

False Positives

Projects that come out of Lean might have product/market fit but can still subsequently fail. Such false positives fail for reasons other than product/market fit such as the resultant product, having iterated, not being as exciting to the stakeholders as the original prospect. Moving too many steps away from an original idea also tends to move you, each time, slightly further away from the original problem to the point where the new problem might not be worth solving. You can end up with a product/market fit for something not worth doing.

As another example of a false positive, there can be problems further down the line building and scaling the product or successfully winning against competitors. This is the situation where VC funding excels.

False Negatives

False negatives also occur when something is rejected, for example, due to unlucky market timing. What might not be viable today might become viable tomorrow. It’s easy to give up too early. It could be your product is one where customers don’t yet know what they want. As mentioned in What the Lean Startup Method Gets Right and Wrong, Steve Jobs once said:

“It isn’t the customer’s job to know what they want“

If your product anticipates what customers might want in the future then the Lean method might not be suitable.

Another example of a false negative is for the class of problems that only become solvable with a complete, full solution. These are ones where you need the whole thing before a valid assessment can be made if it’s viable.

Slow Acceptance

Lean isn’t suitable for ideas that need time to take hold. Lean is quick to abandon ideas and if this velocity is greater than the time needed for end-users to accept a new way of doing things then you might end up moving on too soon and losing a valid product. Big, slow ecosystem type solutions in energy, healthcare, food and agriculture can take a while to play out.

Technical Debt

Another danger with Lean is that it can encourage quick and dirty implementations that subsequently become part of the final solution. It takes strong leadership to avoid technical debt.

Mobile Development Considerations

Given the crowded nature of mobile app markets and the expense of developing for iOS, Android and server, validating your app idea before full-scale development is much more pertinent.

The decision between developing native apps for each platform versus using a cross-platform approach affects the lean startup process. Cross-platform development can speed up the initial launch and learning phases by enabling rapid deployment across multiple platforms, but it often introduces unacceptable trade-offs in terms of usability, performance and access to platform-specific features.

Due to smaller screen than the desktop, user experience and design are very important and can be critical to adoption and retention. Lean Startup methodology in mobile development often involves continuous A/B testing and user experience improvements to ensure the app not only meets the functional needs but also delivers a seamless and engaging user experience.

A core component of the Lean Startup methodology involves building the prototype, measuring how it performs in the market and learning from the results. In mobile development, this can be facilitated by various analytics and user feedback tools designed for mobile apps such as Firebase Analytics and Crashlytics.

The strategies for launching and distributing mobile apps are influenced by the rules and algorithms of app stores. Understanding and optimising for these can be crucial for visibility and success. Tools such as AppFollow can guide you to focus on key metrics that app stores value, such as user reviews and engagement and iterate the app based on performance in these areas.

I have seen that acquiring users for testing and feedback can be expensive and challenging, especially for startups with limited budgets. The cost of acquiring users through advertising or promotional offers can quickly escalate, making it difficult to sustain the iterative testing and development cycles advocated by the Lean Startup method.

Mobile development is subject to the constraints and guidelines of app stores and platforms (iOS and Android), which can limit the ability to iterate quickly. App updates must be approved by app stores. On iOS in particular, this can slow down the iteration process and delay feedback loops, especially for contentious apps that use background activities. On both platforms, while iterating, care much be taken to ensure the app continues to comply with data privacy and security requirements to ensure review failures don’t slow down the lean cycle.

Summary

Lean methodology isn’t appropriate for every startup and there are considerations specific to projects involving mobile development. Lean necessitates an evaluation of the prevailing market conditions and a thorough analysis of the issue your business aims to address. For instance, is your new venture better suited for rapid scaling that requires venture capital? If that’s the case, is there a plentiful supply of venture capital currently available? Regarding the problem being solved, is it feasible to develop a viable, lean prototype? Is it a situation where the customer is unaware of their need for your solution? Will their need take a long time to determine?

Most startups need a mobile app. Developing for both iOS and Android can be time-consuming and costly, leading many to consider cross-platform tools for writing once and running on multiple platforms.

These tools are enticing, offering simpler, higher-level development and compatibility with iOS and Android. However, except for a limited range of applications, cross-platform tools often disappoint in various ways. There’s a risk of investing more, not less, in development effort.

This article briefly reviews the history of cross-platform tools, explores their shortcomings and explains why developers of non-trivial ross-platform apps face a continual uphill struggle.

A Brief History of Cross-Platform

AppForge, predating the iPhone, was probably the first cross-platform mobile development platform, enabling development for Symbian, Windows Mobile, RIM BlackBerry and Palm OS from a single codebase. This is old stuff but please bear with me for some lingering learnings.

My experience using this powerful yet simple tool revealed that despite its cross-platform claim, slight code variations were needed for Symbian and Windows Mobile due to differing user interfaces. New features often lagged behind the native OSs. Oracle’s acquisition and subsequent abandonment of AppForge in 2007 imparted three key lessons that persist in modern cross-platform tools:

1. Supporting different user interfaces with a single code set is challenging. For a genuinely native look and feel, which makes apps feel ‘right’ and appear professional, you’ll need native OS widgets and distinct UI code for each OS.
2. Keeping up with evolving native OS platforms is a colossal task for cross-platform tool developers.
3. The tool’s longevity is as secure as the commitment of its backing team or company.

Since then, tools like PhoneGap/Apache Cordova, Rhomobile, CodenameOne, Appcelerator Titanium, Xamarin, React Native, RxJava and Flutter have emerged.

There’s been a focus on HTML/Javascript, familiar to non-mobile developers and supported by mature Javascript runtimes.

During my mobile career, I avoided cross-platform tools, sceptical of the ‘future is mobile web’ mantra. These tools often posed more problems than solutions. It’s notable that Mark Zuckerberg and AirBnB expressed regret over opting for HTML5 and React Native, respectively.

Despite ongoing developments, cross-platform tools still face challenges. Flutter, for instance, has a very large number of outstanding issues on GitHub and RxJava’s popularity on Android has waned, overshadowed by Kotlin.

The Problems

Cross-platform tools inherently face several issues. Although some can be mitigated with significant development effort, it’s often not financially viable for cross platform providers to maintain this level of commitment. This is due to the constant updates required to match the ever-evolving native iOS and Android platforms and the expanding array of target devices.

For developers, what begins as a straightforward project can quickly grow complex with the addition of real-world features.

Performance – Any abstraction by a tool leads to performance loss. The extent depends on the quality of the higher-level tool. Efficient coding is becoming a lost art. Abstractions added by cross-platform developers, while helpful for understanding, can significantly reduce performance.

Losing OS-level performance features – iOS and Android have finely tuned APIs for threading, scrolling, gesture support, animation and view recycling, often hardware-accelerated. Replicating these features at a higher level typically results in noticeably slower interfaces.

Adopting different idioms leads to performance drops – For instance, React Native’s reliance on serialised JSON can be costly for data-heavy tasks, and its single-threaded nature limits throughput. Performance isn’t just about speed; app size matters too. Cross-platform runtimes supporting all features can be bulky, often bundled with the app regardless of feature usage.

Look and feel – Web-based tools use WebViews, subsets of standard web browsers. Achieving a look and feel close to native Android and iOS requires significant effort due to browser fragmentation. Another challenge is keeping up with the evolving aesthetics of iOS and Android. If a tool simulates rather than utilises actual OS widgets, apps may suddenly appear outdated.

Features – Cross-platform tools bridge or cross-compile features from the native platforms, requiring specific code within the tool for each feature. This is especially true for tools using WebViews, as direct browser access to many APIs is limited Common features include navigation, phone functionalities, specialist libraries and programming idioms. However, as apps evolve, they often need more complex features, leading to the realisation that the platform cannot support a critical function, often forcing a shift to native development or more complex, a Frankenstein mix of cross-platform and native.

WebViews

The expectation that HTML abstracts away platform fragmentation is misguided. Real applications using bridging code in browsers encounter similar fragmentation issues to native development.

WebViews introduce additional fragmentation due to varied HTML support across devices and manufacturers. Achieving functionality across multiple devices can be exceedingly difficult. WebViews also present unique web-based security vulnerabilities, especially on Android.

Breaking Changes in the Native Platform

Native iOS and Android APIs evolve, leading to deprecated APIs and occasionally breaking changes. This can render apps incompatible with updated OS versions. Cross-platform tool users rely on the tool provider to keep pace with these changes, often a daunting task.

Apple Policing

Cross-platform apps risk rejection from the Apple App Store, as Apple may deem them ‘non-app-like’, produced by an app generation service, cross-compiled or using external code. Apple’s stance is that HTML5 apps belong in Safari, not as standalone apps, and their App Store policies are subject to change.

Summary

Using cross-platform tools often leads to unforeseen complexities and limitations. While suitable for simple or short-lived apps and prototypes, critical business apps should ideally be developed with native iOS and Android tools and languages.

Simon is a long-term industry expert who has worked across a number of mobile platforms and is always on top of new and emerging technologies. Simon is highly professional, always delivers above expectation and takes a personal pride in everything that he produces.

Thomas Bailey (while at Sony Ericsson)

He is a very professional mobile expert with the rare blend of great development skills and a strong business acumen. I would highly recommend Simon to potential clients.

Simon Jessup (while at Pixology)

We brought Simon is as a contractor to benefit from his expertise, in order to allow us to complete short timescale, high profile project for a key customer. Simon was able to hit the ground running, quickly integrating with the rest of the local team and working well with our customer’s engineers in Europe. He also coped brilliantly with our customer’s changing requirements. Ultimately, the project was delivered on time to a satisfied customer and we simply could not have done that without Simon’s help and experience.

Stuart Butterfield (while at Philips Research)

Thanking you for the tremendous work that you’ve done this year. We are very aware that not every developer can overcome the hurdles that you have overcome.

Yuval Yashiv (while at IRISS Medical)

Simon is one of the most intelligent and professional business technical expert I have met. Absolutely committed to delivering quality products and projects Simon is highly recommended especially if you need expert technology in particularly in the mobile applications and technology field. I strongly recommend Simon without reservation.

Neil Dixley (while at Sage)

I brought Simon into what was quite a technically involved project well into its development cycle. He was easy to work with, assimilated the concepts and complexities, and went on to contribute to the project in ways beyond our original intention or expectation. I would be happy to work with Simon again.

Brett Connor (while at Oracle)

Simon gave Pixology a massive headstart in their mobile strategy, and followed through with flawless product implementation. Simon produced a cutting-edge mobile print solution within an incredibly short timescale, and his extensive experience of mobile technology was instrumental in it’s success. Additionally, Simons understanding of the mobile marketplace and industry provided invaluable insight and product direction. I would not hesitate to recommend Simon – he is a genuine leader in mobile technology, and consummately professional in all aspects of his work.

Shaun Smith (while at Pixology)

It is a pleasure to recommend Simon – he showed a good understanding of the requirements of the business and a reassuring mastery of the fundamentals of developing applications.

Colin McKell-Redwood (While at Nokia)

This is a selection of work, including my recent assignments, engagements at BeaconZone and earlier mobile projects.

My focus has mainly been on helping companies integrate mobile technology in innovative, usually physical and challenging ways, rather than merely producing an abundance of screens that talk to servers.

Please see my LinkedIn profile for a much larger list of clients and mobile projects.