How to create an App step-by-step

Off-Topic
1

I’m now sure I want to use Xojo for my first professional application. I have some idea and I will tell you more further.

My question is what are the basic steps to reach my goal. For now I make apps for myself and never reach a final user quality application. Often because I always have new ideas to improve and new features to explore.

So professional how do you do ? How do you plan your journey ?

Create detailed application specifications? Define a function list? Draw each window? Create a data model? All this before coding?

Extra: What app do you use to help you in your daily journey to make a solid application?

Thanks for your ideas and suggestions.

2

I’m sure there’s many answers you will get for this as people work differently. There isn’t one right way in my opinion.

For myself, since Xojo lets you easily create windows with controls, and I usually have a good idea of what I want, I usually start by creating at least a first pass at the GUI. After that I just start coding some of the simple stuff for various features. Then I start with the more serious stuff the app will do.

Personally, I don’t like to spend a ton of time writing a design spec since I’m working alone and for myself. If it’s something real complicated, I may start jotting things down and doing some calculations or thinking about what needs to be done. Most my documentation is done in comments in the code and in a separate document as I go or when the project is complete.

2 Likes
3

I have a list of features in a bug/feature tracker called Redmine. The descriptions there usually are rather short.

For my app I make 2 major releases a year. I plan some small features and 2-3 big ones. Those are attractive to users. They mostly don’t notice the small stuff.

For the big feature requests I try to do some planning. I plan the internal data structure changes first. The interface usually comes from the data structure.

1 Like
4

Many of my projects tend to be time-sensitive, which is a nice way of saying - Get this done as quickly as possible because we need it now. The application style tends to be the well-known SkunkWorks project. More can be read about this style here:

I prefer the ‘normal’ style as it makes a nicer paycheck over a longer time. However, the rewards in a SkunkWorks project is usually above average.

5

The last 20% will take up 80% of your time. This is because the core functionality of your app is the “easy” part. It’s closest to your business logic, so it’s the stuff you’re most experienced in. But there’s tons of little polish things that you’re likely not an expert in that will take up the bulk of your time. Things like app update delivery, website, branding, licensing, support channels, and error/exception reporting come to mind. Decide what is critical for version 1.0, and every other idea goes on the shelf for future updates. There is a saying “good programmers ship” which basically means your app is a waste of time until you get it out the door. So set an achievable goal, don’t deviate unless you absolutely have to, get it done. It’ll be tempting to keep adding that one more thing, but you have to resist. Get it done, get it released, then set the goal for the next update and work towards that.

8 Likes
6

I can only describe how I do it, which I don’t know if it has a term or not.

First you break down what you are trying to accomplish, until you understand each and every step. Very time consuming, but its important to be able to visually see what you’re trying to accomplish. I use a whiteboard for segments, which are then transferred to paper, which is then arranged with all the other segments on the wall.

Once you can see the overview, you can begin to focus on the details, begin researching how to accomplish some of the details. Start with what you think are going to be the most difficult first, especially the ones you have no idea how to accomplish at all.

The above point is very important, as you don’t want to get 80% or even 100% of the way through and find that last 20% cannot be done or it cannot be sold in the app store because of some problem out of your control (unless you’re prepared to forgo the segment of the market who ONLY purchases from the App Store).

Edit: Example; Last year I created an animation and wanted to turn it into a macOS screensaver. The tool I used for the animation cannot be used to create macOS compatible screensavers, on research into using a tool that could, I checked how it could be distributed via the Mac App Store. The answer was that the Mac App Store prohibits the distribution of system compatible screen savers, so you’d have to re-invent the wheel and then potentially fight the built-in screen saver functionality and that’s if Apple don’t reject your screen saver for being “too limited in functionality”.

The next step is to prototype anything else that you’re not 100% sure of, for me this is UI. I often go through many iterations that end up looking nothing like my original designs.

The next step is a more complete prototype with the core functionality. Use it as much as possible in this state, it will reveal further issues in your designs or things that need to be done better. Build this as modular as possible, so parts that are you’re happy with can be used in the final product.

Slowly bring in more functionality. Monitor how the new functionality alters the design of your application and its UI.

Do not be afraid to reach out for early feedback or help. I honestly couldn’t build the apps I build without assistance from my dev friends. UI and UX is constantly my weak point (as well as spelling and grammar).

If you’ve reached a point where something isn’t right, but you’re trying to convince yourself that “its fine”, “its acceptable” or “its good enough”. Its time to ask for help.

7

The old 80/20 rule. Which when it comes to programming and estimates for how long it should take, can be paraphrased as “The first 80% of the project takes the first 80% of the time. The last 20% takes the OTHER 80% of the time!” :slight_smile:

8

Just pick a date and publish what you have working…

“new ideas to improve and new features to explore” are new releases.

1 Like
9

At the beginning, there was an idea.

Then, you have to implement it.

To not forget something, you have to create a “Table of Contents” (a synopsys) like if you will write a book.

Start writing the names of the chapters, then enter the subs…

When the ToC ends, you may add what will go into version 1 (as time to release permit) and what can be added later.

At last, during implementation, ideas can come; add them to the original ToC to remember to do it when the time comes.

At last, do not forget to produce that ToC with your client (and add what can be in next versions after he signed that document / contract) to avoid your client add feature after feature while you implement the original job (and for the same price / deadline time).

Remember to ask money as the job evolve; if the client does not pay during the job is running, (s)he can change its mind, take another contractor or Lord know what !

Never share documentation to the client before client sign the contract / give an advance $ for the job.

Of course, if the client forget a feature or want to add a feature, the contract must (can) evolve, as well as the time line and the $.

10

Thanks @Emile_Schwarz for your suggestion. I don’t have a direct client my project is a public application :slight_smile:

11

mindmap, sketches, kanban is helpful.
database layout.
classes and functionality. modules, interfaces.
prevent programming inside of events.
think about if your app should be multi-lingual.
if your apps find a way into store you need time to care this projects.
you have to think about what os targets you will support.

12

word !
at last somebody speaks the truth :slight_smile:

an other way is “better done than perfect”

nice analysis:)

1 Like