SAP Builders Blog Posts
Learn from peers about their low-code journey and write your own blog posts to share your thoughts and experiences as you become an SAP Builder.
Showing results for 
Search instead for 
Did you mean: 


There are so many features waiting to be utilised by you with your next mobile application that have the potential to totally transform the experience of your users and customers. Here I'll be sharing everything I've picked up while developing my photography app, Toast Photography that I built using SAP Build Apps.

Basics with big differences

One of my favourite tools is the shadow tool. This simple yet effective feature is a good starting point at creating depth in an otherwise flat interface. Shadows can also be utilised effectively to create contrast for texts with not so much of a contrast differential, for example text in front of a background image. Setting the shadow in a parent container will lead to the container itself casting a shadow as well as all the children. If you ever have problems with shadows not behaving how you like, here are a few diagnosticsScreenshot 2024-02-09 at 8.58.50 PM.png

  • Transparent containers themselves will not cast any shadows 
  • For a container to cast a shadow around itself, make sure "clip overflowing contents" is turned off
  • Same applies if you see shadows appearing chopped and boxy
  • A rule of thumb for mine is having shadows translucent by 15% for containers and buttons. Texts tend to  have 100% opaque shadows but you can experiment with your environments

Moving on to a next feature: corner roundness. This may not be necessary in a lot of environments, however implementing corner roundness to certain degree renders your UI more visually pleasing. Rounded corners will ensure that the eyes follow a path of lower resistance without pauses or breaks through sharp corners. As sophisticated as our brain can be, they can also very primal in the sense that square edges may have a negative correlation to being sharp while rounded edges are perceived safer and less of a threat. This isn't to say that square edges shouldn't be used but rather round edges can definitely be taken advantage of! A few more basic transformations that I would highly recommend looking into are

  • Custom fonts Screenshot 2024-02-09 at 9.18.58 PM.png
  • Consistent container padding
  • Elements with degrees of transparency 
  • Establishing hierarchy between main components and sub-components
  • Font weights and letter spacing to establish importance, direct the users eye or further define hierarchy 
  • Use of absolute or relative components to establish hierarchy along with defined z-values


Images, Lottie animations, Interface Icons and Boolean variables


This to me be has to be the most fun part of mobile development, suddenly all those hours scratching your head at nested functions and jungles of intertwining logic flows suddenly becomes worth it, you get to relax a little and design your app. Im talking of course about adding some nice visuals to your mobile applications. There are a lot of resources and toolkits to help you build your application into a lively Environment for your customers and users. 


Screenshot 2024-02-09 at 9.55.25 PM.pngI'm sure a lot of low-code builders here are familiar with the image component. I personally use this component a lot as it's the centrepiece of my photography sharing app. However there are multiple ways to display your images. If you use the image component and images in general, it's also important to establish good image practices. As projects scale up, you may soon run into bandwidth problems and low app responsiveness. Caching images should always be done whenever image files are stored on a database and luckily this can be done easily within composer pro with the "cache file" flow function or "set item to storage". An additional layer of image management would be reducing file sizes before images are published uploaded to your database or rendered on your app. This can be handled with the "Resize and reduce file size" flow function. Funny enough I had to learn this the hard way when all of a sudden 30MB images were uploaded by a photographer to my app and they took forever to load, crikey! 

Interface Icons

Luckily the SAP Build Apps environment already comes with an extensive icon Library, These are great for conveying your message without the use of text such as back buttons, like icons or any interface icon in general. There are also tons of resources such as Flaticon and Dribble that interface icons and illustrations of every kind to further meet your specific needs and make your app truly custom and unique. 

Lottie animations

One of my favourite components is the Lottie animation component. I think its worth exploring these JSON based animations as they are a great way to transform your builds from a static app to a more dynamic experience for your users. Lottie animations are infinitely scalable without having too much of a performance impact compared to more traditional animation formats like GIFS and videos. I generally use these for loading screens.

Animate nodes,  flow function logic and variables

Very often you may want components, icons and images to pop up, slide around, wobble or disappear. Playing around with the "animate" component is a great way to archieving such results! However it can get easily clustered and you can loose track of everything. A great way to manage the state or "visibility" of a component that is not static or not defined by itself is by using boolean variables. A good rule of thumb would be preferably naming the variable after that component. This makes it easy and clear to keep work with as well as keeping track of each component and variable within your work flow. Often times you have 10's of variables and multiple other components all interacting with each other. I will use an example of a verification checkmark badge within my app

Screenshot 2024-02-09 at 10.35.51 PM.png

 In this example, users in the app are either verified or not. When a user is verified, an orange checkmark badge appears next to their name. This information is not stored locally so that the user can log in on any device and still be recognised as verified or not so it does to make sense to run a logic flow function to hide the verification badge. Instead this is handled with a boolean variable that is tied to the users account when they sign in. When authentication is complete, the verification variable defaults to a 'false' state unless the users account indicates otherwise. We can go a step further when it comes to using variables and logic to determine weather or not an interface component should be visible on the app, here's another example as well as the problem that needs a solution. 

On the app, you can post a picture story highlight. By default your story highlight disappears after 24hrs but as a unique selling point over other social apps, users can also change the duration at which stories will disappear. Alternatively you can choose an option where stories do not disappear at all for as long as the original poster has not deleted. Sometimes you have somebody blocked and you wish not to see their content on the app or in other situations a post is reported or deleted and therefore must disappear across all users interface...right, where do we begin?

Screenshot 2024-02-09 at 10.49.17 PM.png

 This would be what a solution to a problem this specific would look like. A problem like this can only be resolved with components being tied to variables which allows for advanced controls over your interface components. This formula results in a single True or False output depending on dynamic conditions that are constantly changing and different on each users app as well as being independent to each other. To summarise this formula, the component determines if the story posted in not from somebody you blocked and within the visibility criteria set.

You can leverage powerful functionalities like this with your mobile application builds within the low-code environment while still benefiting from the efficiency of visual building. 

I hope this will serve as a fascinating read as there are fewer limitations to Low-code building and a lot more advantages and possibilities.


1 Comment