Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Question about app development vs scripting for iOS/iPad OS
I was hoping to get your feedback - I’m currently using Windows as my primary system (couldn’t find a suitable Mac) but I don’t want to get bogged down with waiting until I can get a good deal on a portable Mac computer.
Anyways, I’ve found myself enjoying scripting something useful (with the Rename shortcuts/BeatMaker 3 kit creator that I worked on). But I already see some of the limitations - I can’t do as many fancy tricks as with a programming/scripting language. Plus, I’m pretty much dependant on iOS Shortcuts - iOS Shortcuts 13 does not work for devices with iOS Shortcuts 12, so I have to rewrite the code again. I’m still weighing switching to Pythonista for my iOS scripting but I want to give app development a fair shot.
So, I have two questions...
Would it be feasible if I program an app in Objective -C or C++, then possibly get a Mac to do the final uploading? Objective C/C++ seems a lot stable, and since I’m familiar with C, I could write a C code in Windows, then send it to Objective C/C++. Or would I be better off trying to get a Mac and learning Swift, despite every version being different from another?
What Mac would you recommend? I’m reopening the thread I made a while back (seller shipped the wrong Mac but I got it returned; I’m also a little wiser so I’m including a MacBook (Air/Pro) into the list, as well as the Mac Mini) - https://forum.audiob.us/discussion/37421/what-mac-mini-would-you-recommend
(I’d really love to hear everyone’s thoughts on this. Especially @Michael , @wim , @analog_matt , @MrBlaschke, @animalelder )
EDIT: Here's my current thoughts.
So, it's iOS scripting (Pythonista, Shortcuts, Scriptable) for the prototype/test quick ideas, and JUCE (C/C++) for me until I can get a Mac to use Swift and the AudioKit tools. I'll probably make my iOS scripts code more script heavy (E.g. Pythonista), less iOS Shortcuts to make it easier to troubleshoot, but it really depends on the tool.
Comments
How much time are you willing to invest into learning a new programming language and what kind of apps are you aiming at?
I'm planning on dedicating 5 hours a week reliably. For now, I'm focusing on utility apps to get familiar with things (and to solve a ton of problems I find on iOS) before diving fully into music production apps, and maybe eventually a game.
Definitely run OSX and xcode if you're targeting iOS development. Figuring out the nuances of the iOS APIs is a lot of trial and error.
I would suggest you start by learning swift. It is much nicer to work with compared to objective C, and should be sufficient for writing utility apps.
I do not suggest you try any of the other javascript based or web based bridge technologies if your eventual goal is a game or music production applications. They can sort of make utility apps but that's about it.
If your PC is compatible you could consider running a hackintosh, otherwise my personal favourite Mac is still a ~2015 Macbook Pro from before they got rid of magsafe.
I am curious what gave you the impression that you couldn't program in Swift on the Mac that you received that was the wrong one? Was the problem that it was a Mac that couldn't load a recent-ish version of the OS?
You definitely want a Mac for iOS development as others have said.
If you're looking to build iOS/Mac only utility apps, I'd also suggest Swift, it's a much more friendly language to work with.
If you are interested in doing audio apps, check out https://audiokit.io/, which is a really friendly-to-use framework for audio stuff in Swift. It has quite high level components like oscillators and effects that you can hook together to build ideas out pretty quickly. It's iOS/macOS only though.
If you are interested in cross-platform (Windows/Mac/Android/iOS/Linux), or doing lower level audio code, or using your C knowledge, you might like to check out https://juce.com/ which is a very widely used C++ framework for building audio software (though you can build other kinds of software with it too). That way you could get started on Windows and then build your app for iOS when you get a Mac. I'd say Swift is easier to work with if you aren't already C++ savvy though, it's a fairly complicated language, even with JUCE making it more friendly.
It couldn't install Swift. Was running High Sierra, and for the latest one I needed Catalina.
Just my thoughts on IOS programming as a strategy.
I think scripting is a misnomer. Complete scripting tools really just save the compile step by doing that in realtime. So script versus compiler language is not the essential question.
Apple will force you to use Xcode if the target is an Apple product. That's their curse and the fundamental basis for their platform stability. It reduces the complexity of development and testing using state-of-the-art application lifecycle tools.
Juce and AudioKit libraries are great for using existing DSP and GUI routines to supplement the Apple libraries and enable cross system portability with Juce.
So, get Xcode and start building Swift apps. If you ever feel constricted by the limits of Swift which would typically be performance related than consider writing those functions in a C variant.
Mastering "Windows and Mac" app delivery is really a business decision. It creates its own set of constraints for code reuse but the big shops adapt to sell in multiple markets.
ON A SIDE DISCUSSION:
I'd love the know what Pythonista can do relative to the Shortcuts for IOS scripting. Can you get into the IOS file system and write tools to locate and move files in "hidden" app files folders? I'd like to scan my systems for audio files for example to hack some sample management tools... locate, archive, zip, convert, etc.
As far as resources, I found this compendium of iOS programming stuff
https://libraries.io/github/vsouza/awesome-ios
SDK, testing, UI, all sorts of stuff
I actually have a lot of feedback to give as I’m going through the same thing myself. Unfortunately, I am not able to spend any time writing today. You definitely have some options here to fill in the time and to begin learning until you can getA Mac which you will really need in order to publish anything serious on iOS.
I’ll try to share my thoughts late tonight when I get home.
Thanks for the tips so far.
Most iOS apps, including Pythonista are sandboxed, so they can only work within their storage. You can send files into it for processing and output files via Share. But I think there's a bit more in that app, as they even have a Pythonista keyboard for easy scripts.
Thanks. I guess I can see why these IOS devices need to be highly secure. This sandboxing restrictions over file access are probably in place for writing Swift programs too. Duplication of audio samples is just a by product of the platforms security implementation. It's great when a developer exports in useful forms to helpful locations.
Good luck digging into app dev. You might ping some of the smaller/newer dev's to share their lessons learned like @coniferprod who wrote the SynthJacker app. Really nice guy.
If you want to do most of your coding on Windows, JUCE is your best bet.
Pyto has some libraries for working with the file system as you can now do with the files app to access other apps’ file spaces. It even has some (complicated) ways to return results from calls to other apps. I haven’t come up with anything useful to use it for, but it’s interesting to learn Python.
Can you import any packages into it for doing things like web downloading scripts?
@rs2000 gave me the Unix commands to pull every script to of patchstorage.com for example. I'd probably recode the process to a python app on IOS if there is "wget" like
functionality available.
Yes. All “pure python” libraries, as well as many others import just fine. I’ve even used it to connect to MySQL databases.
There are libraries that can scrape data out of web pages, including intelligently from web tables.
Pythonista is the app most extensively used on iOS. I use Pyto ‘cause I got for free. But it makes no difference.
You can run python from Vim iOS too.
Pythonista can work with external files and folders belonging to a different app but that app has to support this and only a few do. The best example is Working Copy. You can open one of its Git repositories in Pythonista as an external folder and all the changes will be saved directly to that folder, no need to send files between these two apps. Also, it can be a folder from iCloud or “On my iPad”
Too bad not many apps support this feature called “open in-place”. I’d love to keep all my samples in iCloud and all my music apps just work with that external folder
@Samflash3 you can start learning Swift without a Mac. Swift also runs on Linux. It will be just pure command-line Swift and some basic libraries i.e. no Mac/iOS UI SDKs, but enough to start learning the language, its syntax. You just need a Ubuntu VM in VirtualBox.
Btw, if iOS shortcuts is not enough and you don’t like Python, there’s also Scriptable
Yeah, scriptable looks like it has potential. I’ve added it to my list, but I need to make a set decision. I guess I could combine Siri Shortcuts + Pythonista + Scriptable for the full featured experience I need.
I actually like Pythonista and have the app, and with a lot of things in mind, it would probably be easy if I just stuck with Pythonista. Plus, I do see myself needing C, Python, Javascript, and SQL for my career.
@analog_matt and @tdmusic - JUCE is a great recommendation. Thanks. I was almost going to look into Xamarian for Windows/Mac OS. I’ll set my focus to be a bit lower, as my main computing device has switched from a Windows PC to my iPad. I do use the Windows computer, although it’s dropped from 100% to 40%.
@burns_audio and @tdmusic Excellent point about the need for Swift for music apps. I’ve vaguely done swift programming with Swift Playgrounds/Apple sessions. It’s a different syntax, but it’s not impossible. The problem is that for the near future, getting a Mac OS computer might be a bit difficult. I could Hackintosh my current WIndows computer but I’m not sure if it’s supported.
Good to know. If the Hackintosh migration doesn’t work, I’ll probably do this. Could this work on a Raspberry Pi?
I feel cross platform is really important to me. I’m the type of person who wants to help people collaborate. Which is weird, because in school I always hated it when people tried helping each other in exams.
C/C++, Python, JavaScript, and SQL seem to be the most platform agnostic languages. I could then learn specific languages like Swift to build around these structures. I’ve already done beyond the basic tutorials on all those languages listed (except Swift) but I’ve not made any personal projects with them...yet.
Looks like it could: https://github.com/uraimo/buildSwiftOnARM#prebuilt-binaries
But since it's ARM, not Intel, I don't know how well it will work, whether you can use its standard library, etc.
When we started out developing apps I spent time looking at cross-platform tools. We were working on Dell laptops with Mac OS installed on them. It didn't work out. If you choose to use a technology that isn't what the majority of developers are using then you are making things harder for yourself. If you don't believe me now, wait until you get several months into a project (like we did) only to find out that there are bugs in the tools you are using, or you can't get help when things go wrong because nobody else is doing it the way you are. We have been in this business for 9 years now and I still find it very hard. There is so much interaction between so many different pieces: host apps, operating systems, hardware, other plugins. And things just keep changing every time Apple updates iOS. You don't want to make it harder than it already is. Find out what tools the majority of developers are using and invest in a computer that can run them.
I've heard good things about JUCE so I recommend you try it if you need cross-platform. However, cross-platform is overrated, in my opinion. If you write your audio code in C (not c++) then you should be able to port it from iOS / Mac to windows without too much trouble so you don't need special cross platform tools to make that work. But when you go to do the GUI, if you use cross platform tools you will always be limited in terms of what features they support. If the signal processing code is the main thing then why worry about the GUI? You can just code it again on each platform and it will probably run more smoothly that way anyway. On iOS you really need vDSP signal processing library to make audio code efficient, so that's another big obstacle to truly cross-platform code. vDSP runs on both iOS and Mac but when I've tested it on Mac OS, it's often not any faster than just writing standard C code and letting the compiler figure out how to make it fast. Intel compilers are apparently very smart. They have signal processing libraries for windows like Intel IPP, but I'm still skeptical about whether or not that makes a big improvement over well-written C code compiled with all the optimizations on.
Whoa, this was a post I wasnt expecting but I really needed this.
So, what I'm getting is that I really should get the Mac as soon as I can, preferably something that can last for a few years.
In the meantime, I should spend some time polishing my C programming, while trying to accomplish current needs via iOS scripting.
I'll make one small edit. I'll also look into JUCE as it's based off C++. I believe Steve Duda mentioned that his regret was not knowing about JUCE earlier.
Yeah, sorry my post sounds a bit pessimistic. You might have a different experience from what we had, if you write a different style of apps. I expect JUCE to be quite good because so many people praise it. We don't use it because we have chosen to focus more on developing high quality signal processing code, rather than piecing pre-existing components together. As pre-existing components go, I would expect the ones in JUCE to be quite good though. So it depends on what kind of apps you want to develop.
The Attack Shaper is a perfect example of something that can't be built from putting together JUCE components. We could have built it in JUCE but we would have had to write most of the code ourselves anyway so I'm not sure what benefit we would get from using JUCE for that.
C is fine, I love C but... I wouldn't start with it.
When you start developing an app or a desktop program, you never know how your code will look at the end (unless it's something very, very simple). You try diff ideas - some work, some don't. You usually rewrite some parts of your code several times, you do some refactoring when it starts to look messy.
My point is: it's much easier to do when you use a higher-level language like Python or Swift. Then, when you are happy with your prototype and you need some of your code to be cross-platform and/or faster, you can rewrite it in C. Like writing a book - you don't start translating it into other languages when it's not finished yet
Agreed. We don't start in C. Personally I love to prototype in Mathematica and Matlab. C is what I use only when I'm actually ready to build the app.
or you can write everything for yourself in C++/assembler :-)) I kniw one iOS music app developer who is doing this way, which leads to kung-fu level of CPU efficiency even on very old devices :-))
not that soon... you can develop whole app in C/C++ usig visual studio on windows, test it there, and only after you will have first working app, you will need mac just for compilimg it to decice emulator, or tomyour phone or for appstore build...
NS2 is made exactly this way, Matt is doing 90% of work in Visual Studio on Windows and he basically uses old mac mini just as final building machine for testing it on phone and deploying to appstore ..
So no, in final phase you don't need mac, until you don't have at leas some basic product.. And for this purpose some second-hand mac mini would be enougn. you don't need state of the art new computer ;-)
Of course - for non realtime audio app, i would choose completely different approach - my choice would be Mac, Xcode and Swift.
Or even HTML/JS and Cordova, if you're familiar with javascript - it's great way how to make CPU-not sensitive apps quick way, and it even has advantage of deploying same app for iOS and Android.
But again - this is NO way for audio apps, just for utility/tools.
@Samflash3
Look what i got in my news for you today
https://www.appcoda.com/musickit-music-player-swiftui/
Listen to wise words from @Blue_Mangoo. I would definitely not set up a long-term hackintosh platform for development, that is a rabbit hole of ever sorting out troubles specific to your setup (meaning, hard to find answers online). My old Mac Air is from 2012 and still running fine. I haven't checked whether I can use the latest Xcode, though.
Unless you are a DSP guru crafting your own audio algos, then optimized C routines is not where you'll spend most of your time. Don't underestimate all the work to get UI and other stuff to patch together, and for this you'll for sure use some object-oriented language (likely swift or objective-c). You mention C familiarity, but do you have experience in object-oriented design? I know python does object classes, but I also know many just use python as a scripting language without classes
Anyway, that's where I would start if skills were lacking in that department (and for this you wouldn't need a Mac). You'll definitely do all UI etc with object-oriented code, even though your audio routines might be in C (I say might, because it's a good chance you'll just be calling other frameworks - many or most people do 
Speaking of that ... I think AudioKit was great when I looked at it. Today I would definitely have checked out Juce, too. Here is a recent praise from Mathieu Garcia of Beatmaker fame:
Hard-core pros will say that the best is to build your app with no such frameworks, though. It certainly helps to be independet of third-parties if one can manage to do all by oneself. For instance, I've seen from twitter or forum comments that AudioDamage base their apps on Juce, and they've had some long-standing bugs that needed to wait for an update to the Juce library. Such is life when you depend on third-party frameworks.
Btw, I tried to do some audio app development a few years ago, when AUv3 was rather new. The lack of documentation from Apple back then was shockingly poor - some parts regarding Core Audio are well documented, but they keep launching new stuff and redesigning their frameworks without bothering to put out complete documentation. This is really hurting your motivation when trying to get your first app off the ground. I don't know, maybe it has improved, but I still hear about having to decode WWDC videos and .h files to understand how to piece stuff together. It is quite some work to keep up.