From Idea to App Store: How I Built an App Using 100% No-Code Tools

This is the full account of how I built SpaceTable using no-code tools.

__________

One of my main goals with No Code Founders has been to evangelize the power of no-code tools and help non-technical people with entrepreneurial mindsets to launch their own businesses.

The possibilities with no-code are endless and I wanted to showcase both the technical possibilities of no-code as well as how fast the learning process can be, so I decided to build a project in public and attempt to demonstrate both of these aspects. The idea was to build a semi-complex mobile app in 4 weeks or less using tools I had never used before, so that I could give an accurate depiction of the learning process from start to finish. In this blog post, I will cover the entire process of how I went from knowing nothing to having an app in the App Store.

Before I begin, it’s important to note that whilst I’ve built and sold several no-code companies in the past, I’m not a particularly technical person. I definitely skew more towards the entrepreneur side of things, rather than the software developer side. No-code for me has always been a means to an end - a route to building businesses where I didn’t need a technical co-founder. So if you’re not overly technical, I hope this guide will help to demonstrate how no-code tools can help.

For this project, I wanted to build something for Twitter. This meant using the Twitter API. I had never worked with APIs before so this meant actually dealing with a small amount of code! In case you’re not familiar with what an API is, it basically allows you to pull and add data to a 3rd party service. In this case, that service was Twitter. The Twitter API allows you to do things like sending tweets, following users, and pulling lists of tweets. By connecting the API to your own created app, you can add that functionality to the app allowing you to make all sorts of interesting apps.

The Idea

I had a few ideas for apps I could build so I started out with a Poll on Twitter (where else) with each idea and allowed people to vote for their favourite.

The winning idea was to build an aggregator for Twitter Spaces. “Spaces” in Twitter are a relatively new feature where users can host their own audio rooms where people can chat via the Twitter app with audio only. I didn’t realise at the time that the Twitter API didn’t include Spaces as it was too new a feature. As luck would have it though, they added it the very next day so I was able to start playing around with it.

The app itself would be quite simple from a user’s perspective as it would effectively just be a list of Twitter Spaces that could be browsed. I chose the name “SpaceTable” for the project and purchased the domain SpaceTable.co.

The Stack

The next thing I had to do was to choose the tools I would use to build the app. I decided to use Draftbit to build the front-end (the actual designs and screens that the user interacts with). I’m a little more comfortable with UI design than I am with back-ends so I chose Draftbit because of it’s power to build really powerful App-Store-ready apps whilst not being a massive learning curve - I relate it to being like Webflow for mobile apps.

Draftbit allows you to connect to various backends where your data will be stored. I decided to use Xano which allows you to create your own databases but also has powerful features that can connect directly to 3rd party APIs which was exactly what I needed. If you’re a software developer, a tool like Xano will be immediately easy to use and will speed up your backend work enormously.

For me, I was less familiar with backends or working with APIs so it was completely new and a bit of a learning curve. For my app that was basically pulling data from Twitter, the backend was going to be powering most of the important functionality so getting this right was my biggest job. The Xano team were unbelievably helpful though and it didn’t take long to get my head around how to set it up.

The Functionality

The normal Twitter app only shows you Spaces that are:

Happening right nowBeing hosted by people you follow

There’s no way to browse other Spaces. This makes it very difficult to find Spaces that you might be interested in as you basically just need to be online at the right time. The idea with creating a Spaces aggregator was that I could bring all of the live and upcoming Spaces together in one place allowing users to browse Spaces and jump directly into any that they might be interested in - effectively allowing you to discover new Spaces.

As is often the case however, the Twitter API made this much harder than expected...

The Backend (Xano)

Although I had no experience of working with APIs, I knew roughly what I wanted the backend to be able to do, which was:

1. Search the Twitter API for Spaces with specific search terms
2. Add them to a database
3. Do this on a recurring basis
4. Remove Spaces from the database once they were finished

Unfortunately, the Twitter API made this much trickier than I initially anticipated. Firstly, it required that a search query was entered, so I would need to add a query of “startups” for example and hope that there were some Spaces with “startups” in the title.

As Spaces is a relatively new feature however, it was hard to find keywords that would bring up a decent amount of results. Not only that, many Spaces get created without a title but they still show up in results so I had to find a way to exclude these.

Because I could only search by a single query, I had to find a way to input multiple queries to generate larger lists of results. This then also caused there to be duplicates in the database since there would be results that contained more than one of the search queries, so I also had to add a way to not add duplicates to the database. 

An additional layer of complexity was added by the fact that Spaces can have one of two states, either “scheduled” or “live”. From a user’s perspective, I thought it would be much better to split these into 2 separate areas in the app, as it wouldn’t make much sense to have live Spaces included in a list of scheduled Spaces.

This meant possibly creating 2 databases - but the problem with that is that if I added a live Space to a database, it would still show up as being live on the app, even when it had finished. This led me to have 2 separate approaches:

1. One API which pulled Scheduled Twitter Spaces and wrote them to a database
2. Another API which pulled Live Twitter Spaces directly to Draftbit (without writing them to a database) so that the data was up to date

Setting up the database

Building the database in Xano is exactly the same as setting up a database in a tool like Excel or Airtable. You can add standard columns such as Text, Integer or Boolean, as well as more advanced types such as Geography or JSON. I checked the Twitter API and found the fields that were available that I could pull through. The Space data is distinct from the User data in Twitter so I had to set up 2 databases, 1 for users and 1 for Spaces. I then just created fields in each database for the data that I needed to pull through.

For Spaces, these were:

Space_idTitleScheduled_start (date/time for scheduled spaces)Creator IDState (Live or Scheduled)

For Users, these were:

User_idNameProfile_image_URL

Twitter API

With the databases setup, I now had to create the API in Xano that would search Twitter for Spaces and then add them to the databases.

The above is what an API endpoint looks like in Xano. It’s split into 3 sections:

Inputs - where you can pass data into the APIFunction stack - where you add all the functionality

Response - Where you can return a value to the frontend

I started by creating an input which was a Text input that I called “space_query”. This gets passed to the function stack in step 2. By creating this as an input, it allows me to pass a value to the function stack via the front end, through a search bar for example. The alternative to this would be to hard-code a specific search term into the function stack e.g. I could have hard-coded the search query “food”, but this wouldn’t allow the end user to control the search query.

Step 2, the function stack, is where all the magic happens. This is where you can build advanced functionality for the backend that you wouldn’t be able to do using a tool like Airtable. I wanted the API to find spaces based on the input in step 1 and then save it to the Spaces database and then also add the user to the Users database. It also had to ignore all search results that didn’t have a title, as they wouldn’t look good in my app search restuls. Here’s how that final setup looked:

This took care of adding the Spaces to the database. I now also needed a method to remove these however once they were finished. The easiest way to do this for the scheduled Spaces was simply to delete them from the database once the scheduled_start date was less than the current date/time. This was done through a separate API that would DELETE Spaces rather than GET them. Here’s the setup for that:

I soon realised that I had to get results for multiple queries, not just one at a time, so I ended up creating another database called “keywords” where I entered about 10 common words that might be used in Space titles e.g. “Startup”, “Food”, “Music”, “Art” etc and then changed the input on the API to loop through this array of search terms and deliver results for all of them. Here’s how that looked:

Connecting Xano to Draftbit

The first API that I setup above pulls the Twitter spaces through to Xano and adds them to the Xano database. We then need to setup another API that will pull the items in that database and display them on the frontend (Draftbit). That API is a much simpler one to setup and looks like this:

As you can see, there are no inputs on this API and the Function stack is simply querying all records from the Spaces database we set up earlier. I called this API “Spaces” and it will display the full list of Spaces in the Spaces database on Draftbit. As well as this, I also had to set up a 2nd API that would display an individual Space. Here’s how that looks:

This has the same name as the previous API but just has the addition of {spaces_id} at the end of the endpoint name. The reason for this is that it passes the Space ID through this variable so that when we click on a Space from a list in Draftbit, it will pass the ID and take us to an individual Space and be able to reference all the data from the Space with the matching Space ID.

Now that we have these APIs setup, we can just copy the Endpoint URL at the top of the screen and paste that into Draftbit to connect them (more on that later).

Dealing with Live Spaces

As mentioned above, writing Live Spaces to the database is more problematic as they may end 5 minutes after being added, meaning the results will no longer be accurate. One option to get around this is not to write them to the database at all but to send the live search results directly to Draftbit instead. So I worked with the Xano team to come up with a final API which could pull live results. The tricky part is that it requires a search query so I created an input on this new API and passed a search term from a Draftbit search bar through to the API. This meant that the Live Spaces in the App would only display if a search term was entered. The Function stack of that API was the most complex one yet and looks like this:

I connected this to a search bar in Draftbit so that users could search for live Spaces. Unlike Upcoming Spaces, the Live Spaces screen required a search term before showing any results. The issue I found with this however was that it was really a shot in the dark as the majority of search terms rendered 0 results. This wasn’t great from a user’s perspective as it looked quite boring when no search term was entered and when they did enter something, more often than not it still had zero results which made for a very poor experience. So I wanted to come up with a way of doing this where I could write the live spaces to the database too and then remove them quickly so that I could display accurate results immediately, without having to enter a search term. That’s where functions and tasks come in...

Functions and Tasks

I already had the API setup for Scheduled Spaces which was working great, so I figured I could replicate this, simply changing the search from Scheduled Spaces to Live Spaces.

I then also setup new databases for Live Spaces and the related Users. This would give a list of Spaces that were live right now, so I also needed a way to be able to clear the list on a recurring basis. So I converted the live Spaces API in Xano to a “function”.

A function looks very similar to an API. Here is the Function I set up for the Live Spaces.

Functions allow you to save an entire workflow that you can then reuse anywhere you like. I then created a Background Task in Xano which allows you to run things in the background on a one-off or recurring basis. I added the function that I had just created into it but also add a step before it that would clear the Live_Spaces database.

I wanted it to recur so I set it to repeat every 2 mins. This way, it clears the database every 2 mins but immediately populates it again with more Live Spaces. This approach gave the best of both worlds as I could have a populated database and be confident that the Spaces were Live in the past 2 mins so had a high probability of still being live. Here’s how that Task looks:

I then also converted the Scheduled Spaces API to a Function and added that to a Task as well. This had a slightly different setup in that it wouldn’t delete all the Spaces, but would loop through them and check for those where the scheduled_start time was less than the current time i.e. they were either finished or were now live, so you’ll notice this Task has an additional function in there to delete those Spaces.

The Frontend (Draftbit)

I knew I didn’t need to have a lot of screens for the app. In my mind, there might only be 3:

1. List of upcoming spaces
2. List of live spaces
3. Individual space page

Having never used Draftbit before, I wanted to play around with it first to get my head around the setup.

I started with the editor:

A couple of Draftbit features stood out to me right away from a design perspective. Firstly, you can literally type the name of a colour into the colour selector for an element. So you could just type “red” rather than looking up a hex colour. Really useful for quickly testing out design ideas.

Secondly, is this preview option where you just scan the QR code on your phone and it brings up a preview in a testing app. I used that a lot when trialing designs to see what it would look like in the live app. Unlike with web design where you’re building for the web inside a web browser, I was aware that mobile app development is much harder to accurately preview in a pixel-perfect way so this approach made it far easier to accurately check my changes in a live environment.

Once I had my head around the basic principles of the editor, I started by trying to build a basic welcome screen for the app. I published this little video on Twitter which shows how fast the design process can be. This welcome screen concept took less than a minute to build.

Next up, I wanted to build out the interface for a list of Twitter Spaces. Draftbit includes template screens that you can add to your app. I chose the Contacts template as the layout seemed suitable for a list of Twitter Spaces. Later on, I ended up completely overhauling the design once I was more familiar with the Draftbit interface, but at this point it helped me to jump straight into some designs and learn as I was building.

I then reworked the designs and created a vertical list view:

And then a 2nd design which included a section at the top for live Spaces.

Then I ended up creating a darkmode just for the fun of it.

I liked this feature of being able to switch between vertical and horizontal stacking of elements. This means I could create a view and then add an icon and text within them and then stack them horizontally to create nice little titles. Draftbit’s layout engine is all driven by flexbox which makes it easy to create responsive layouts that will work well on all screen sizes.

Draftbit has a bunch of icons already built-in (13,196 to be precise) so I didn’t need to find any 3rd party icons and could drop them straight into the design.

So now I had a welcome screen and list screen. I just needed one more screen for an individual Space and then my basic setup was done. The individual Space screen is the screen users will navigate to when they click a Space in a list and be taken to the item view for that Space. The first version looked like this:

Connecting to Xano

Draftbit has a bunch of options when it comes to connecting a backend. As I was using Xano for my backend, it was just a case of copying the Endpoint from Xano and pasting it into Draftbit.

Then I created individual endpoints for the different record types I was creating in Xano. I started with three separate endpoints:

Space - For pulling individual SpacesSpaces - For pulling a list of SpacesUser - A list of Users

These endpoints allow you to pull through data from the backend which are either being stored in a database or even directly from the 3rd party API. In this case, I stored them all in a Xano database and pulled them from there. Once the above setup was in place, I could then start pulling data dynamically into the screen designs in Draftbit. Here’s how that works:

The above screenshot shows the “Space” level view which displays an individual Space. You can see the highlighted section shows that I have connected to the Service I setup with Xano and then connected it to the specific endpoint for the individual Space. Then, in the next section down titled “URL structure”, I have mapped the ID of the Space from the Xano database so that it knows which Space to display each time.

Creating variables

When it comes to displaying data for each individual Space, you can create variables which reference the data from the backend. In this example, I wanted to add the username of the Twitter user who is hosting the Space. To do this, I added a text field that I wanted to say “Hosted by...” followed by the username.

I created this by creating a variable called “username” by simply adding the word “username” in double curly brackets. Draftbit then creates the variable and allows you to map that variable to a field from the Xano database. In this example, I mapped it to the username field which will dynamically populate the variable for the relevant screen a user is viewing at any given time.

Limitations of the Twitter API

As the Twitter Spaces API is brand new and Twitter Spaces themselves don’t contain many data points, I was very limited to what I could add from a design perspective. The only data points I had were:

Title of SpaceDate of space (if scheduled)Username of hostProfile picture of host

The limited data meant that I didn’t have much to play with in terms of making the design interesting. To make things worse, the avatars that the Twitter API provides have very small dimensions which meant that they were blurry if displayed at any decent size - see below:

This meant I had to rethink the entire design. The avatars needed to be much smaller to prevent them from being blurry so I would need to rely on the textual elements to make it as visual as possible. I’m normally a fan of minimalist design, but the white background of the app without any images was looking far too sparse so I played around with other ideas to make the few elements on the screen look less dull. I ended up with a few design changes to make it a bit more interesting. These changes included:

1. Changing the background colour to black. I may lighten this a little to a charcoal colour to make it less intense.
   
2. Centralising text and button on the individual Space screen to make them take up more of the empty space.
   
3. Adding more space between the elements so that there was less empty space at the bottom of each screen.
   
4. Changing the font from a Sans-serif standard font to a Serif font to give it a more interesting “vintagey” vibe.
   
5. Changing the button colours to the Twitter blue to add a visual link to Twitter.
   
6. Header text was changed to white.
   
7. Secondary text such as the host name was changed to grey so that it didn’t distract from the main titles but added some tonal variation to the colour schemes.

Here are the resulting screens after those changes:

Adding navigation

My initial plan was to avoid adding a navigation bar but instead include a switch where users could toggle between live Spaces and upcoming Spaces. The issue with this is that I wanted to add a search bar for searching for live Spaces so they really needed to be on separate screens.

The way navigation works with Draftbit is that you can add Stack Navigators or a Tab Navigator. Stack navigators allow you to navigate between screens like a stack of cards, so that when you move to a screen, it brings that screen to the top of the deck and allows you to move back to the same point in the list.

Tab navigators on the other hand allow you to create a tab at the top or bottom of your app screens with navigation options. In this case, I wanted the Tab navigator so that I could add 2 options at the bottom of the main screens which were:

1. Upcoming Spaces
2. Scheduled Spaces

This would allow users to quickly toggle between Spaces happening right now, or upcoming Spaces they might want to add to their calendar for later.

To do this, I went to the Navigate tab in Draftbit and added a Tab navigator in the left-hand menu and then just dragged the 2 screens that I wanted to be added to the navigation. Then, within the right-hand sidebar, I configured the default screen and the styling of the menu. I made the active screen text colour white and the inactive screen dark grey and then added a couple of relevant icons to make it a bit more visual.

I then reworked the homepage to be a simple welcome message that described what the app does which they can then immediately click through to the aggregated scheduled Spaces.

Publishing to the App Store

I was now ready to publish to the App Store. There are a few different steps to this process but it’s pretty easy overall. Here are the steps:

Setup Apple Developer accountSetup Expo accountExport code from DraftbitUse Terminal to add build it onto App Store ConnectUse Terminal to submit to App StoreTest via Testflight AppPublish via App Store Connect

The first step was to setup an Apple Developer account which is as simple as completing a sign up form using your Apple ID if you have one. This took less than 5 mins to setup and cost $99 for an annual license.

I then also had to setup an Expo account which handles the entire build process of turning your Drafbtit app into an App Store ready iOS app. I did a free trial of their paid version which makes the build process much faster.

Step 3 was to export the code from Draftbit which is as simple as clicking the Export button in the Draftbit editor and the exported code gets emailed to you.

There are then a couple of commands to run in the command line to build that code in Expo and then submit it to the App Store. I’m not overly familiar with the command line but it’s only a couple of commands and is documented here in the Draftbit support docs.

Once that was complete, I could then view the app in App Store Connect which is where you need to supply the relevant data for your app. I downloaded Apple’s Testflight app where you can test the app on your own devices.

Unfortunately the first version wasn’t approved as Apple thought that my app allowed users to submit their own data so it needed to have more features to prevent graphic content etc. but I explained that it didn’t have any user generated content so which was then passed.

They then came back to say that it also needed a way for users to be able to flag offensive Spaces so I went back to Xano and created a new API that deleted a Space from the database when a Space ID was fed in and then created a “Flag as inappropriate” text on each Space in Draftbit that would run this API when clicked.

I also had to add an info screen and added a small “i” icon to the top-right corner of each screen to allow users to view this.

When I submitted this version, it was accepted and I was able to then complete the rest of the details for the App Store such as the description etc. I created some screenshots on Canva and used these as the App Store images.

After submitting that, it was then live on the App Store within 24 hours. I found that each review process with Apple usually only took 24 hours but I’ve heard they can take several days.

Conclusion

Having never worked with either Draftbit or Xano or 3rd party APIs, this project was an interesting challenge for me. Even though the end result is a simple app, the functionality it includes is actually quite complex. If you would like to check out the finished product, you can download SpaceTable on iOS here.

For this app, most of the work was done on the backend as the API setup was quite complex so resulted in a lot of work being required in Xano.

Having never done any API work before, there was a bit of a learning curve in setting this up but not too big and I’m not an especially technical person. I think a tool like Xano would be loved by backend software developers as it can speed up a lot of the backend setup.

Draftbit was much more familiar for me and I found most of the design really easy to set up. The Xano and Draftbit teams were both really helpful though and walked me through every area I got stuck with.

If you would like to create your own project with Xano and Draftbit, you can sign up on the links below:

Sign up for Draftbit

Sign up for Xano

Also published here: https://www.linkedin.com/pulse/from-idea-app-store-draftbit-xano-joshua-tiernan-jt-/?trackingId=bCwmW1nW0iE744waoqJV8g%3D%3D