Exploring new areas in technology and changing longstanding practices can be challenging. However, the knowledge and resources gained in this process can create many subsequent opportunities for improving innovation cycles.

This year at the ETH Library Lab we set out on a journey: trekking through the winding valleys of software development, tip-toeing across the expansive glacier of the iOS App Store until finally reaching the heady heights of deploying our first app. The name of the project: BioDex, its goal: to enable biodiversity research with automated species identification. The resulting BioDex App, specifically designed for use in natural history and entomological collections.

From a proof of concept phase with strong focus on insect classification in the previous year, we had now established our basecamp, a rough prototype running on Google Cloud [1]. Our intention for this year then was to improve the species prediction model and create a new mobile app to improve the user experience. With these objectives in mind, we set out in the winter months of 2020 to find our course…  

Setting out into the vast unknown of app development – figuratively at least. “Ski Touring” by Christopher_Hawkins, CC BY-NC-ND 2.0

Choose Your Own Adventure –  The Design Stage 

The main project phases (image credit: B.Sunderland)

The design phase is a vital part of any project. We wanted to create an app that has a workflow specifically suited to people working in natural history collections (i.e. people who are sorting many specimens in a day). Consequently, our priorities were to have an ergonomic layout that minimises the number of steps between photographing a specimen, viewing the results and starting again. We created mockups [2] of each screen and sketched out the workflow to visualise these layouts. Taking this time upfront to clarify your own thoughts and clearly communicate your ideas with others can save a lot of time once development starts.

Venturing into unknown territory is more likely to go smoothly if you can enlist the help of others. For this, we enlisted the development services of fellow Technopark residents, Propulsion Academy, who handled the Full Stack development of the Mobile app. Our planned route was quite simple; for ease of organisation, and for flexibility after completion, we would split the project into two main parts; the Full Stack App Development and improving the Prediction API. This would give the flexibility to easily update the prediction model in the future, without needing to change the mobile app.

Map of our planned route (image credit: B.Sunderland)

We tried to focus on including only the most important features for the app to function well; anything extraneous was noted and set aside, for possible addition in the next release. Our aim was to complete the full cycle of releasing the app and getting user feedback rather than unnecessarily spending time on features that were not needed.

In retrospect, reflecting on the project from my personal perspective, it’s clear that the journey would be better represented from another angle!

The development from another perspective (image credit: B.Sunderland)

Take Home Points 

  • define which features are essential for the App’s functionality
  • detail how these features will look, function and navigate between one another
  • set a time limit for feature development

Development  – the Hike to your Destination

Soon after starting development on the app, we decided to invest the time in developing our own infrastructure to host the project internally rather than on Google Cloud. This shifted the focus of the project away from Data Science experiments to improve the prediction model’s accuracy, to instead creating the full stack infrastructure that would facilitate hosting the model and mobile app on our own servers. With limited experience in web development, we knew this particular aspect would be a challenge. However, the key learning was that delays were rarely caused by major decisions or problems, but rather by the accumulation of the many small day-to-day issues and questions. Compounding this effect, modern full stack applications – particularly ones using machine learning – will use many different libraries and frameworks, and when working as a single developer it takes time to switch between these, especially when using them for the first time. The benefit of regular access to technical support to quickly solve these issues should not be underestimated.

Motivation is the single most important factor in any sort of success”
Sir Edmund Hillary [3]

To combat these challenges, one should aim to create features that are just fit for purpose and are not over-engineered and complicated. Ideally, keeping the right balance between developing features quickly (using simple approaches) and only spending time optimising code when necessary.

Balancing the minimum optimisation to keep your project running (image credit: B.Sunderland)

In addition to the development work, I underestimated the amount of time needed to work with a third external developer. We were fortunate to have a great working partnership but the onus is still on you to make decisions along the way and supply the developer with assets, designs and clarifications that they will need to contribute to your envisioned app. 

Take Home Points 

  • junior developers are most effective when they have convenient access to more experienced developers for day-to-day problem solving (or can work as a team)
  • beware of optimising your software before it is necessary 
  • working with third party developers effectively requires a considerable amount support of time

Deployment – The Push for the Summit 

As is now common practice, we containerised [4] each part of the project for easier deployment, stability and future scalability. And future is the keyword. Containerising your project is an upfront time investment to avoid issues at a later stage; meaning that your project is more transportable and can quite easily be deployed to different servers or ensure that other contributors can reliably recreate your project.

Despite the benefits of containerising a project, it cannot completely replace the need for some testing in the actual deployed environment, where some operating system version or security protocol could have an impact. We were fortunate to have a test environment for this purpose that replicated the production server.

Deploying your project can feel a little exposed at times, so it is useful to have a safe practice space for testing. “Climbing the Dragon Wall” by herbraab, CC BY-NC-ND 2.0

Take Home Points 

  • try to provide early access for developers to a hosting environment that replicates the production environment 
  • project requirements can change rapidly in the early phases of a project, so avoid spending a lot of time on specifications
  • carefully consider the costs of cloud hosting vs. the time required to host on-site 

Distribution – The Home Stretch 

To create the Android and iOS versions of the app, we used a cross-platform approach using a framework called Expo which will build native versions of your app for both platforms without having to write additional code. The philosophy of Expo is to abstract away the complexity of authenticating your app and releasing it to the app store. In our experience using their process only works if you have an iOS developer account that has permission to release an app. This can create an extra hurdle in larger organisations with defined security protocols such as ETH Zurich, in such a setting it may be worthwhile paying for a separate Apple developer account to free up this process. 

Some of the screenshots displayed in the App Store (image credit: B.Sunderland)


Take Home Points 

  • frameworks can abstract away complexity, but usually restrict flexibility 
  • apps may get rejected by Apple on the first submission, budget additional time for correcting small issues or improving the content in the app store 

Looking Back on the Journey 

A major consideration for future projects will be to determine if making an app for the Play or App store is the best decision. And if so, how will there be separate Android and iOS codebases or will you use library that supports building for both platformsThe use of the term “app” has become so commonplace that is worthwhile checking what is really needed before committing to developing one. Web browsers’ capabilities have improved so much in recent years that the majority of apps could be implemented just as well in a modern website. And if users still need the ability to use the app offline, it is worth considering creating a Progressive Web App (PWA) [5], which allows users to continue working with the app and then synchronise with the backend once they are back online.  

The right choice depends on the use case and the resources available but removing the complication of publishing through the app store can save a lot of time. It is a matter of considering if the potential improvement of brand recognition and discoverability is worth the time and cost investment to get your app approved by Apple and Google.

A key question in the process, is to decide if a mobile app is the best implementation (image credit: B.Sunderland)

Being good at development takes practiceand with each trip through the development life cycle, things will go much faster. Especially if you take the time to create services that can be reused in the future. 


We were supported and given advice by many people throughout this process and would like to extend our thanks for their assistance:

Sven Koesling & Johana Llakmani of ETH Library IT (BIT), Max Schlapfer of ETH IT (ID BD), Dominik Hug of ETH IT (ID SWS), Dr. Matthias Töwe of ETH Library, Björn Scheiwiller , Cedric Delacombaz, Daniele Roncaglioni & Nitin Kumar of Propulsion Academy, Dr. Silke Meyns of ETH Transfer, Dr. Andrei Plamada & Dr. Uwe Schmitt of ETH Scientific IT Services, Dr. Michael Greeff of ETH Zurich Entomological Collection

Footnotes and References

[0] BioDex iOS App  (android app to follow)

[1] Specifically, we used a google cloud function which takes care of a lot the complexity of creating an api endpoint.

[2] We used the free tier of a tool called Moqup for this purpose which is probably more suited to teams with a dedicated UI/UX developer. Since then, we’ve been using Whimsical (similar to Miro) which has less detailed control over the visual and interactive elements of the design, but is faster to use and is easier to include the navigation between screens.

[3] From “Sir Edmund Hillary and Reinhold Messner: King of the Mountain” – What It Takes

[4] A container is a self-contained unit of software that packages up code and all its dependencies so the application runs quickly and reliably on different computers and servers. Learn more here.

[5] See more explanation and description of the benefits here.

Article related tags


Barry Sunderland

Technical Engineer ETH Library Lab, Alumnus Innovator Fellowship Program

We use cookies to help us give you the best possible user experience on our website. By continuing to browse the site you are agreeing to the use of cookies. More information about privacy can be found here.