You know what the biggest problem in writing an app is? It’s not the code, it’s the things you dont know. Things you need to get your app into shape.
Advanced users say just ask and as far as coding goes this is sage advice but what about the things you dont even know you don’t know. For example when I started to use databases I didn’t know about SQL injection (which is so very obvious to many) so all my apps were wide open to such an attack. And I wouldnt have been able to ask about it either.
What is missing is a primer of “do’s and don’ts”, so I thought I start this thread, and maybe we can come up with a nice long list of things to know
That is one of the main purposes of forums like this one.
What you don’t know, but do know to ask… you can ask
What you don’t even know to ask about, perhaps someone else will, and you will see the topic and learn something you didn’t know you needed to learn… And THEN you know enough to ask more…
SQL injections as well as Perl and php injections were not known until a victim found out. Then countermeasures could be implemented. Same thing for viruses. In the late seventies we had no idea such replicating code could be created. And it took a year or so for makers like McAfee and Norton to devise the first antiviruses.
By nature, you cannot predict the future. You can only try to prepare for it. I believe a well structured program is key to adapt to the unknown. But we cannot live in fear of tomorrows.
Sandboxing… Designing your application to work how you want while still being sandboxed.
Testing, get your significant other (unless they’re a computer geek) to test your application, they’ll find the most weird ways in which to break your application!
User interface, agains said significant other, if they have to keep asking you how to do something, you’ve written it wrong!
Application icon, it’s good to start designing this while you’re developing the application. If your icon sucks, it’ll let down your application.
Product name; is it appropriate? Is it to abstract? Take App Wrapper or HDRtist Pro for instance, descriptive app names and these work well. Where as “Shine” confuses people (it’s for generating light rays btw). You see if you have to start explaining the app name, you’ve lost already!
Salability; think about how you want to sell it; especially on the App Store as there is no Free Trial, one of the hardest things for me is figuring out how to create a totally useable FREE application with enough reasons for people to purchase an upgrade. You’ll need to look at your competition and think about how you can do a better job, especially if you’re launching a new application.
All-in or upgrade slowly or Apple v.s. Samsung. Do you want to ship a product quickly to test the market, then release updates. Or, would you rather build the best you can and go all out on product launch. The App Store also influences this decision, as with the App Store you get one shot of limited visibility (as updates are not re-listed) so if your app fails to take off out of the gate, you’ll miss the App Store audience.
Marketing; how are you going to get your target audience to be aware of your product and what makes it worth their hard earned cash?
Haha, indeed. In fairness, Apple have been making some better attempts to highlight different apps lately, with lots of little human-curated groups of apps. It’s not enough.
Agreed with Michael on the Mac App Store, it’s still easier to get noticed there.
Maintainability : in your source code, write detailed notes not only about what a method or function is doing, but why. I tend to leave old source code in the functions but commented out as well, so the future me can see how I tried doing it at first.
Years later, I often find myself thinking “Hey, it would be a great idea to do XYZ here” and if I already tried XYZ and it didn’t work, having those notes to myself is very valuable.
[quote=210916:@Markus Winter]You know what the biggest problem in writing an app is? It’s not the code, it’s the things you dont know. Things you need to get your app into shape.
Advanced users say just ask and as far as coding goes this is sage advice but what about the things you dont even know you don’t know. For example when I started to use databases I didn’t know about SQL injection (which is so very obvious to many) so all my apps were wide open to such an attack. And I wouldnt have been able to ask about it either.
What is missing is a primer of “do’s and don’ts”, so I thought I start this thread, and maybe we can come up with a nice long list of things to know [/quote]
To get back on topic, I keep code reusability at the forefront of my thought process when I’m making apps now. In my younger years, I was super-focused on one project at a time but nowadays I’ve so many little projects going on, that a lot of work is recycled again and again. This is especially relevant in the App Store era, where apps are often a flash in the pan.
So, I’d say follow good OOP practice and try for a little MVC, at least keep the model as separate from the views as possible.
Here’s a question I am have - what is “sandboxing”? It’s a term I have read here many times and seems to have great importance (or is a hindrance) when preparing an app for the AppStore.
Sandboxing is a required security mechanism for apps on the App Store, it limits what an application can and cannot do, where it has access to and so forth. If the app gets compromised, the scope of potential destruction is minimized by the App Sandbox.
Considering that OS X is already a ‘safe’ environment, Sandboxing is more of a hinderance at the moment.
Although in all irony; if I were to write a virus/worm/destructive entity, I would start by removing the Sandbox from a potential host and then wreaking havoc.
I think with Xojo under the right circumstance MVC is brilliant, but for a lot of cases it can just an extra layer of complexity. I had to fix some older apps to work on the fourth coming OS X, and one was designed with MVC. Oh how I wish it wasn’t…
[quote=211065:@Sam Rowlands]Sandboxing is a required security mechanism for apps on the App Store, it limits what an application can and cannot do, where it has access to and so forth. If the app gets compromised, the scope of potential destruction is minimized by the App Sandbox.
Considering that OS X is already a ‘safe’ environment, Sandboxing is more of a hinderance at the moment.
Although in all irony; if I were to write a virus/worm/destructive entity, I would start by removing the Sandbox from a potential host and then wreaking havoc.[/quote]
Sandboxing will also be mandatory in the Windows 10 Store. It no longer accepts listing of Desktop apps download sites. Next year, the Centennial Bridge program will enable Win32 apps (read Xojo) to run as new API Universal Windows Programs which are sandboxed. Chances are many current things today, like writing files into the app executable folder, or accessing critical parts of the computer, Documents, Pictures, etc. without the user consent or without a specific setting, will be forbidden. Maybe calling shell as well.
People who already got good habits designing apps for Mac sandboxed will not be already familiar with these stringent rules. will have to problem conforming. Others who have been doing Windows apps the old way (“I have always put my data files in the program folder, why does it not work ?”) may need some retraining…
That is where spaghetti code entrenched into controls may have a slight problem refactoring…
Maybe FileMaker will finally be forced to change their ways, I’ve encountered so many FileMaker developers who are furious after building their app and then not being able to ship on the App Store and FileMaker don’t care, I always suggest that it they should consider Xojo at this point
Not so sure Filemaker will ever care about the App Store apps. I have not studied their market for the longest time, but they feel very corporate and probably don’t give much of a thought to consumer market.
What could be an interesting project would be a FileMaker emulator written in Xojo, that takes FileMaker sources and generates a Xojo project. Of course that would require someone who is well versed in both apps.
The Filemaker people are very corporate and they are slightly crazy. Or who would try to do database synchronizing with Filemaker?
I’m going to a regular meetup with some Filemaker developers and it’s totally fascinating what you can do with the software. And very special. There is a musics professor who is doing accustical excersizes with Filemaker.
I think one of the biggest challenges is not so much the technical side, but rather how to produce software with features that consistently hits the bulls-eye in terms of what users want.
It doesn’t mean much if a project is on budget, in time, with unbreakable security, if it turns out that it doesn’t add enough value to the life of the user, for them to buy and recommend your product.
It is very rare that programmers and directors always knows exactly what the user wants. I realize a lot of people loves quoting Steve Jobs with “Customers don’t know what they want.”. I think this quote is sometimes used out of context, and are used as an excuse to build software based on personal opinion, rather than building software based on concrete data and evidence of what users want.
How many projects or startups fail simply because too much time and energy is invested in building features or applications that that users don’t want?
Quite frankly, users know EXACTLY what they want, and they will indicate this to you by the way they vote with their wallet.
Anyways, this is what I find most challenging in the software industry, learning the art of building stuff users want, to effectively reduce the time and energy wasted on features users don’t want.
