Im trying to start in app developing. What would the most simple app one can create using some tutorial so i can get an idea of how app development works? The app doesn't need to have any kind of functionality, just having the ability to swiping to pages, have a menu etc. I only want to be able to set things in some app lookalike environment, like creating a demo mockup of an app.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
developing the most simple app
- Thread starter zoran
- Start date
- Sort by reaction score
I only dabble in coding (though I wrote my first app in 1971), so I'm not the best person to answer. By all I've read (and the playing around I've done in Swift Playgrounds), it's a very capable language, with the potential to become even more capable - in its short lifespan, it seems to have won many admirers.
Once more, I'll refer you to an Apple web page. If you scroll down just a little, they mention a number of major apps that use Swift. https://www.apple.com/swift/
Don't worry whether this will take you down the wrong career path. If you become a serious coder, this certainly will only be the first of many languages you learn. I recommended it because Playgrounds is a great way to do what you asked - get a start in app developing. Maybe the interface seems a bit childish to you? Don't let that stop you or fool you. Swift is a professional tool, not a toy.
Once more, I'll refer you to an Apple web page. If you scroll down just a little, they mention a number of major apps that use Swift. https://www.apple.com/swift/
Don't worry whether this will take you down the wrong career path. If you become a serious coder, this certainly will only be the first of many languages you learn. I recommended it because Playgrounds is a great way to do what you asked - get a start in app developing. Maybe the interface seems a bit childish to you? Don't let that stop you or fool you. Swift is a professional tool, not a toy.
What is bugging me is the fact that i can't put Swift Playground App on my iPhone+ or even some kind of iPad emulator for the iMac to see it there!
I do wonder though when one creates an app, how can he troubleshoot it to see if its working?
I do wonder though when one creates an app, how can he troubleshoot it to see if its working?
Last edited:
It's pretty basic, however, part of the problem - I always wince a little when I see someone say, "I want to learn programming, how do you do X/Y/Z in XCode [or some framework]?" - is with most modern development, there's a number of concepts to understand, on top of a basic programming foundation. With an iOS app, you need to know Swift or Obj-C, and all the UI tools (IB), and how to navigate XCode, and ...
I mean, I get wanting to start with something visual (the intent with Swift Playgrounds), but it's easy to get overwhelmed by the development environment, and miss getting a good understanding of the underlying language (and general programming concepts). That's why so many programming courses start out with languages outside of any kind of IDE, just simple, command line execution with a text editor.
I understand your wincing and i do understand what you mean and will not oppose to it. You see, us designers (me) live in the world of WUSIWUG and command lines are a whole new world for us, not to say that we do hate them 
so its normal for us to try to find the easiest way to do programming.
so its normal for us to try to find the easiest way to do programming.
It's pretty normal for everyone to attempt to find the easiest way to to do something. We try to make it easier by writing better compilers and inventing better common practices. But in the end, learning to code is just like learning a new spoken language. Start simple with 'Hello'. Then, quickly move on to the important things like, 'May I have a beer' and 'Where is the bathroom'. Next thing you know you'll be fluent enough to know what you do not know....so its normal for us to try to find the easiest way to do programming.
I have been writing code for over 30 years and still learn new things ( better ways of doing something ) with every project. There is always someone more clever to learn from. That is why I love coding, being humbled by someone with less than one year's experience is amazing.
Just dive right in and start showing us your stuff.
Besides the Mac native XCODE/Swift programming, Processing could be interesting for you to learn the basic programming concepts. It was long time promoted as language for people working in visual arts: https://processing.org
It looks like I copy/pasted the explanation and not the process. Sorry. This will be much easier.
https://www.appcoda.com/learnswift/build-your-first-app.html
I'm shocked that nobody has suggested Cordova/PhoneGap. ESPECIALLY in a forum called "Web Design and Development"!
The easiest - and I would argue best - way to create "the simplest app" is by using Cordova/PhoneGap or other similar hybrid approach.
Cordova provides a native app framework that uses a WebView (embedded web browser) for UI. You supply the web pages and perhaps some Javascript.
You want a mock-up? Do it on your desktop system. Create web pages, and view them in your desktop browser. (It's helpful to use Chrome debug features that will size the browser window to that of ppular mobile devices.) And - the thing is - it's isn't actually a mockup. It's what you will actually use in the app.
When you are ready to make an app, you just put the HTML pages into a designated directory in the Cordova project, and then build the project (using e.g. for iOS XCode).
It is helpful to learn some Static Site Generator, like e.g. Jekyll. (I like Middleman). A SSG will give you many/most/all of the tools you might be used to when developing sites using a traditional server backend. So, you can use templates to make it easier to use repetitive bits of HTML, for example.
Hybrid app platforms are criticized for not creating "real native apps". But, in fact, they do. The framework itself contains native code, and is compiled with the native development stack. The framework exposes device capabilities that wouldn't be available to just a website running in the system browser. And, when you HAVE to, you can still drop to native code by writing a native extension.
Hybrid app platforms all support at least iOS and Android, so you get an app that runs on both rather than having to start over with an entirely different set of tools and APIs. (You still have to install a second set of build tools, though, to build for Android.)
Another criticism of hybrid apps is that they don't "replicate the native look and feel". Well, that's rubbish, as they can with some CSS. And, IMO, native look and feel is overrated. There are lots of applications where it is a negative. For example, for serious apps used by businesses (most you will never see on the App stores) it is a decided DISADVANTAGE to have apps use "native look and feel". It's better if it works the same way on every device, which makes it easier for the help desk, and easier to train workers on how to use the app.
I'd wager that MOST apps deployed in private "Enterprise App Stores" are using some sort of hybrid platform. BYOD ("bring your own device") is VERY popular, as companies don't want to have to buy a device for everyone, and employees balk at carrying an extra device. The cost of building native apps for two device families (iOS and Android) is prohibitive, as it requires separate teams with different skillsets. Developers need to keep up, and really, it is difficult to keep up with two quite different development stacks.
A valid (but increasingly less important) argument against is that Javascript in the browser is not the best way to create UI elements run your business/program logic, etc. I agree with this one to a degree - I recall several years ago creating a Cordova app using jQuery Mobile as a UI framework. JQM "enhances" widgets, manipulating the DOM after page load. It was decidedly sluggish moving from page to page. I'd expect similar results with more modern client-side MVC frameworks like Angular or React - if used on several-years-old hardware! But the hardware is faster today, and especially on iOS if you use a WKWebView (rather than UIWebView) JS in the webview is blazing fast.
I don't use Cordova presently - I use a different hybrid framework called Rhodes. Rhodes works a bit differently, as it provides a "Ruby on Rails"-like server within the app. The HTML pages make requests to the server, the server makes pages using an MVC, and you write the MVC code in Ruby. (The Ruby code is compiled to Ruby bytecode at build time, and so it does not violate the "no interpretive languages" App Store prohibition).
There was a move toward a similar approach for Cordova through a third-party plugin that put a node.js server in the Cordova app. However, I think that effort was abandoned. FWIW, Rhodes is adding node.js as an alternative/concurrent internal server option in an upcoming release. (You could use BOTH the Ruby server AND the node.js server...)
If you already have done some web development, then you should consider the hybrid approach. And really, I would give very little consideration to pure native. You can have you prototype up as quickly as you can make a few web pages, and a real app in a matter of days. (The time it takes to learn how to install and use the tools.)
The easiest - and I would argue best - way to create "the simplest app" is by using Cordova/PhoneGap or other similar hybrid approach.
Cordova provides a native app framework that uses a WebView (embedded web browser) for UI. You supply the web pages and perhaps some Javascript.
You want a mock-up? Do it on your desktop system. Create web pages, and view them in your desktop browser. (It's helpful to use Chrome debug features that will size the browser window to that of ppular mobile devices.) And - the thing is - it's isn't actually a mockup. It's what you will actually use in the app.
When you are ready to make an app, you just put the HTML pages into a designated directory in the Cordova project, and then build the project (using e.g. for iOS XCode).
It is helpful to learn some Static Site Generator, like e.g. Jekyll. (I like Middleman). A SSG will give you many/most/all of the tools you might be used to when developing sites using a traditional server backend. So, you can use templates to make it easier to use repetitive bits of HTML, for example.
Hybrid app platforms are criticized for not creating "real native apps". But, in fact, they do. The framework itself contains native code, and is compiled with the native development stack. The framework exposes device capabilities that wouldn't be available to just a website running in the system browser. And, when you HAVE to, you can still drop to native code by writing a native extension.
Hybrid app platforms all support at least iOS and Android, so you get an app that runs on both rather than having to start over with an entirely different set of tools and APIs. (You still have to install a second set of build tools, though, to build for Android.)
Another criticism of hybrid apps is that they don't "replicate the native look and feel". Well, that's rubbish, as they can with some CSS. And, IMO, native look and feel is overrated. There are lots of applications where it is a negative. For example, for serious apps used by businesses (most you will never see on the App stores) it is a decided DISADVANTAGE to have apps use "native look and feel". It's better if it works the same way on every device, which makes it easier for the help desk, and easier to train workers on how to use the app.
I'd wager that MOST apps deployed in private "Enterprise App Stores" are using some sort of hybrid platform. BYOD ("bring your own device") is VERY popular, as companies don't want to have to buy a device for everyone, and employees balk at carrying an extra device. The cost of building native apps for two device families (iOS and Android) is prohibitive, as it requires separate teams with different skillsets. Developers need to keep up, and really, it is difficult to keep up with two quite different development stacks.
A valid (but increasingly less important) argument against is that Javascript in the browser is not the best way to create UI elements run your business/program logic, etc. I agree with this one to a degree - I recall several years ago creating a Cordova app using jQuery Mobile as a UI framework. JQM "enhances" widgets, manipulating the DOM after page load. It was decidedly sluggish moving from page to page. I'd expect similar results with more modern client-side MVC frameworks like Angular or React - if used on several-years-old hardware! But the hardware is faster today, and especially on iOS if you use a WKWebView (rather than UIWebView) JS in the webview is blazing fast.
I don't use Cordova presently - I use a different hybrid framework called Rhodes. Rhodes works a bit differently, as it provides a "Ruby on Rails"-like server within the app. The HTML pages make requests to the server, the server makes pages using an MVC, and you write the MVC code in Ruby. (The Ruby code is compiled to Ruby bytecode at build time, and so it does not violate the "no interpretive languages" App Store prohibition).
There was a move toward a similar approach for Cordova through a third-party plugin that put a node.js server in the Cordova app. However, I think that effort was abandoned. FWIW, Rhodes is adding node.js as an alternative/concurrent internal server option in an upcoming release. (You could use BOTH the Ruby server AND the node.js server...)
If you already have done some web development, then you should consider the hybrid approach. And really, I would give very little consideration to pure native. You can have you prototype up as quickly as you can make a few web pages, and a real app in a matter of days. (The time it takes to learn how to install and use the tools.)
You do not need cordova / phonegap ( something about the hubris of Adobe products that just rubs me the wrong way ). Package all of your HTML/CSS/JS into a folder and load it into a WKWebView. Or do as I do and try Electron:
https://electron.atom.io/
I did not mention any of those, because they are a bit beyond 'the most simple app'.
Last edited:
I completely disagree. I get hired to rewrite Cordova/Phonegap/Xamarin apps. It's a terrible approach to app development because you're relying very heavily on frameworks that aren't up to date on day one (despite their claims) when a new OS rolls out. Not to mention the sheer quirkiness of applications developed with those technologies.
@OP If you want to learn app development, start with Swift. Not the Hello World that was linked above, that's Hello World for iOS SDK. You want Hello World with just plain Swift.
Grab the book "Hacking with Swift", you can read it free online and it will start you off with a true Hello World which is nothing more than:
print("Hello World.")
I understand your wincing and i do understand what you mean and will not oppose to it. You see, us designers (me) live in the world of WUSIWUG and command lines are a whole new world for us, not to say that we do hate them
I get the design angle, I had a successful (acquired in 2000) shop that started out, and operated for years as mostly design work, even when we pivoted to include some web work (mid-90s). I worked, and was friends with, a bunch of highly talented designers, many with deep agency experience.
I also get wanting to program-without-programming™, decades ago, things like Hypercard, and later [Macromedia/Adobe] Shockwave [Flash], trying to put more of a design metaphor on top of a development environment (and was actually pretty successful). However, just like with design, you want to learn some fundamentals, some of the "language" that provides a foundation to learning the tools.
i.e., design isn't about knowing Photoshop, iOS development isn't about knowing how to drag-and-drop some UI elements.
I totally dig on the idea of learning some Swift, independent of full on iOS development. In the past, I've suggested languages like Python* or Ruby. They give you a good sense of control flow, basics of classes/objects, syntax, understanding how to invoke methods, declare variables - and very importantly, how to use documentation to find answers.
(* I love Python ...)
Sure, you can create an app using Swift or Objective-C, instantiate a WKWebView, and do the rest of the programming in the WebView. And I'm sure you can find some nice starter templates for that.
But then you are on your own when it comes to exposing native capabilities that aren't available in the WebView.
And then you start all over with a new set of tools to create an app for Android.
Of course you don't have to use Adobe products. I don't. I've done one project a few years ago with Cordova. It is a travel (destination-related) site - basically a static website poured into an app, with some map interactivity added. Cordova is a pretty good choice for that sort of app, IMO. I don't think I'd want to use Cordova for something with a lot of interaction with an API, a lot of local data storage (local database) etc.
I do my hybrid mobile work with Rhodes.
Unless i am misreading the site, Electron is for creating desktop applications for Windows, Linux, and MacOS. I don't think that's what OP wants.
I am sure there are plenty of bad Cordova/Phonegap/Xamarin apps out there begging to be re-written. But it is usually bad design and amateur implementation, not the choice of tools.
And then you start all over again for Android in Java (yuck!)
Right now, I am re-writing a badly-designed native iOS app as a cross-platform hybrid app. It's already way better in so many ways than the original. Bad design choices are bad design choices, and switching to a different set of tools (generally) does not fix them.
(I say "generally" because one of the bad design choices was to use the ill-fated Parse BAAS...)
I don't know what kind of apps OP has in mind - he didn't say. Yes, there are many small app producers that make apps for the public and concentrate on one platform - iOS or Android. RARELY have I seen a small app producer that writes GOOD native apps for both platforms. They usually wind-up abandoning one or the other, and concentrating on the one they know best. The more common complaints I see is that one or the other platform lags in terms of new features, they may work different, one may be more buggy, etc. etc.
For BYOD Enterprise apps (what I do mostly) you do not have the option of building only for one platform. It has to be for both iOS and Android. Writing native probably adds 50% to the cost. The total cost of the types of apps I work on tends to range in the $1M to $2M range typically over a 1-2 year period. That includes app, back-end, testing, training, the company's internal effort to define the problem, etc. It's an expensive process already, without doubling the app development team!
There is very, very little that really NEEDS to be native. I can and will drop to assembly language where I have to. I haven't had to for a few years. For a current project, one critical part (iOS and Android - on Android the Rhodes framework uses the NDK) is in C. At the same time, I wouldn't dream of writing an entire app in C, or C++, or Java or Swift. Always the highest-level that faces no significant performance penalty.
For most UI tasks, that highest level is CSS, with some help from Javascript. The skills are widely available, you can involve designers directly in the app design without having to "throw designs over the wall" to a programmer. Both iOS and Android support remote inspection of webview-based apps from Safari/Chrome, and so for fiddling with UI nuances, you hand a designer a device with the app and a USB cable and let them have at it!
Last edited:
No offense but it sounds like you don't make even remotely complex apps if you think very little needs to be native. When you make more complicated software you'll realize native really is the only way to go.
I can't imagine what correlation there could possibly be between "complexity" and the need for native code.
Indeed, the more complex the less attractive native becomes. Complexity means more code. I want as much code as possible to be in the highest-level language with the greatest specificity to the task at hand. Java/Swift are seldom that!
I had a revelation early in my career. I ported an application from mainframe Fortran to IBM PC Fortran. (Watcom, actually). It's an application that does variation simulation analysis (VSA). 35 years later, BTW, it still lives - it's now called Siemens Team Center Visualization VSA. The manufacturer of your car(s) disk drives, any commercial aircraft you've flow on - probably used it to model assembly variations.
One of the difficulties at the time was that mechanical engineers had to model assemblies in Fortran. It was difficult, the code was hard to read, it took a 1/2 hour compile/link cycle to try out a model. I designed a language specific to creating variation models. It had primitive types for e.g. points, lines, planes, fixtures, assemblies. Way more intuitive than Fortran arrays!
I implemented a compiler for the language. Instead of producing machine code, the compiler produced a bytecode. The bytecode was INTERPRETED. The interpreter was written in FORTRAN, fergoshsakes! Now an engineer could try-out a model in just a few seconds. But how ever was that going to perform well?!
Very well, it turns out. Almost all of the time was spent in statistical and matrix functions, written in Fortran. And Fortran was (and still is) pretty darn good at that kind of stuff. The time spent in the interpreter running loops, if statements, etc. was peanuts in comparison. We hired a mathematician to clean-up the Fortran library code - fixing the bugs, using heuristics instead of the classic algorithms that had been used by the university professor who originally wrote the application. A very tiny bit of code was re-written in assembly language.
At the start of the project, there had been little hope of getting the PC version to perform as well as mainframe. In fact, it wound-up beating the mainframe version by hundreds of percent. It enabled a revolution in manufacturing and was quickly adopted by the big-3 auto makers, airframe makers, etc. The FA-18 E/F was modeled head-tail in this language as part of the effort to fix the problems with that airframe.
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA379633
(5.2 Variability Control)
VSA modeling enabled the first use of HOLES (instead of slots - and costly manual alignment) to assemble car hoods to bodies. (Corvette, BTW). (Today, though, models are defined interactively on a graphics screen. I don't know if the language I designed is still used, but I do know that at least a few years ago, the graphical definition of models still produced source code in the language I designed.)
Point being? Performance has nothing to do with what language is used to create an application. It has to do with correct and well-performing algorithms, and the APPROPRIATE use of languages for the task at hand. I almost ALWAYS use a mix of languages, and every one of my hybrid apps has some amount of native code - which I keep at a minimum because it has to be re-written for each platform.
I learned early on that good performance comes from understanding where the application spends it's time - identifying the bottlenecks and dealing with them. A language as low-level as Swift or Java or Objective-C is rarely needed for the bulk of the code in application development.
I suppose it was a lucky happenstance that the purpose of that particular application was, in fact, to identify a sort of "bottleneck" in the design of mechanical assemblies, and I saw how the product was being applied. How much do you think your car would cost if every machining operation were done with the utmost of precision, regardless of need? The key is identifying WHICH operations require HOW MUCH precision in order to avoid rejects. The same approach can and should be applied to software design. WHICH bits of code require a low-level language, require native APIs, etc. to meet performance goals? A blanket application of the use of expensive, low-level tools and APIs is just fool-hardy and excessively costly. No matter what Apple tells you.
---
Some input from OP on just what he considers "the most simple app" would be helpful. And whether it needs to run on both iOS and Android. We've already heard from him a hint that he feels that native may be too complicated for his tastes. With some specific input, we can give more specific advice.
I think perhaps we've misunderstood his intention a bit. I think by "most simple app" he wants a small example to see what is involved. Something more than a "hello, world", but not that much more.
Still, it is useful to know what sort of app(s) he intendeds to eventually create, and for what platform(s).
Last edited:
I'm not reading your enormous posts. Native is always better, hands down. As far as complexity when you start needing to dive into animations, core graphics, or new features like AR Kit, you're not able to when you use ******** frameworks like Phonegap and Xamarin.
You may be able to do some stuff, but not all of it, not even close. Not to mention your UI will always suffer. Non-native apps don't ever feel the same and that IS important.
The only people who support Phone Gap and whatnot are one trick ponies too afraid to learn real programming.
You may be able to do some stuff, but not all of it, not even close. Not to mention your UI will always suffer. Non-native apps don't ever feel the same and that IS important.
The only people who support Phone Gap and whatnot are one trick ponies too afraid to learn real programming.
You're welcome not to.
So are stainless-steel bolts. But they are almost always not needed and not cost-effective.
SVG with CSS animation, WebGL, use the graphics processor for acceleration, and will meet most of these needs. Have you seen/tried any of the amazing high-performance JS graphics packages?
Just plain not true. That's where I would use a native extension.
Can we tone-down the incendiary language? There's no call for it.
Another sweeping generalization. What's important is what's important for a particular app/audience/customer.
If you'd read or at least skim my enormous posts, you'd realize I've been doing real programming for more than 40 years. And at least one of my early efforts is still in use after 35 of those years, and has made a tremendous contribution to improving the quality of manufactured products. I've done all sorts of firmware projects working at the lowest level of code, in some cases counting machine cycles (for an early microprocessor-based CNC controller that was Allen-Bradley's first micro-based controller.) I think I know when to use low-level code, and when to use high-level code or no code at all. If I have to write "native" code (whatever that is... to me... assembly code is native code...) I write native code. If I have to write a compiler, I write a compiler. But I don't blindly write assembly code or a compiler for every project!
Phone Gap "and whatnot" are a great way of creating a wide variety of simple and not-so-simple apps, including MOST apps in the Enterprise space. They can be used by the completely untrained to create some simple apps, and can do amazing things in the hands of a capable developer who knows how to pick the right tools for the job and isn't afraid to drill-down to native code WHEN IT IS NEEDED.
So, how would you go about replicating your apps for Android? Or is it a non-issue? It may be a non-issue for you, but it isn't the for 60% (or more) of people who carry Android devices rather than iOS. Good luck finding the time to learn Java and all of the Android APIs, and then keeping-up with all of the constant updates to both. What if your app has to run on Windows, too? Do you have the time to keep-up with 3 platforms? Maybe your projects have the deep pockets to hire 3 development teams.
Last edited:
Guys i admire the fact that you all stated plenty of solutions to start with, but to be honest i cant keep up with what you all suggested. Plenty of info but im totally mixed up with I wish there was someone to pinpoint me to the right direction, after all helping me is the point here and not arguing what is best or what it can do.. I still feel like im still at the beginning of my search... help!
I wish there was someone to pinpoint me to the right direction, after all helping me is the point here and not arguing what is best or what it can do.. I still feel like im still at the beginning of my search... help! Guys i admire the fact that you all stated plenty of solutions to start with, but to be honest i cant keep up with what you all suggested. Plenty of info but im totally mixed up with
We can't point you in the right direction without knowing just what it is you are trying to accomplish. You've given us precious little to work with. I've asked several questions that have gone unanswered - perhaps they got buried in all the back-and-forth.
I think people have all made assumptions of what you are trying to accomplish in the absence of detail, and based on their own biases.
Let's start with:
- Do you have a particular app in mind that you want to write? Or do you just want to learn how to "write apps"?
- Do you at least have a particular category of apps that you are interested in? e.g. Games, productivity, social media, etc. etc. etc.
- Are you interested in creating speculative apps for the App Store, or are you looking toward a career writing for others? If the latter - again - what kind of apps? There are a large number of apps that are never published in the App Store. These are typically "Enterprise apps" - apps that help run a business. Home Depot has apps. McDonalds has apps. They are for their employees. They are not in the App Store.
- Do you want to write apps for iOS, Android, or both? What about desktop - Windows, MacOS, Linux? Chromebook? It is important to answer this one. IMO, anybody who claims that they can write native apps for all of the above (and keep up with all of the changes) is lying or at least stretching the truth. If you learn to write iOS native apps, you will have learned almost nothing that you would need to know to write Android native apps!
- What if any experience do you have with writing software (of any kind)? Have you had some schooling in it? Do you have some experience with creating websites using HTML/CSS/JS? If you have some experience at the latter, it would be very helpful if you choose to go the hybrid-app route, and of almost no use in creating purely-native apps.
- What programming languages do you already know, if any? What level of expertise do you have with them?
I realize you thought you were asking a simple, easily-answered question. It really wasn't. It's hard to give advice without knowing just what you are trying to do or learn.
Last edited:
My thoughts exactly, I didn't reply to their most recent post for just the reasons you outlined. Maybe with a little more clarity we can provide a better response
Ok jtara i think now we are going to get somewhere…
- I don’t have a particular app in mind no
- Games and Social media certainly not at the moment. I guess i don’t even know the list of app categories that are available as you divided them into… what other categories are there?
- what does “speculative apps for the App Store mean?
- iOS or Android, i guess an app should be made for both, like kill two birds with one stone, but i would like your help on this, what is recommended to do?
- Nope, none experience of programming, or website development with html, or css etc, im a WYSIWYG design guy 100%
- I don’t have a particular app in mind no
- Games and Social media certainly not at the moment. I guess i don’t even know the list of app categories that are available as you divided them into… what other categories are there?
- what does “speculative apps for the App Store mean?
- iOS or Android, i guess an app should be made for both, like kill two birds with one stone, but i would like your help on this, what is recommended to do?
- Nope, none experience of programming, or website development with html, or css etc, im a WYSIWYG design guy 100%