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.
Strange error message on Mac, latest Big Sur
![[Deleted User]](https://secure.gravatar.com/avatar/c65f3204a06d27ec73276b6045ed7d23/?default=https%3A%2F%2Fvanillicon.com%2F91feed79a2b1ce0d17ae51ed4913d76d_200.png&rating=g&size=200)
The user and all related content has been deleted.
Comments
It could be a configuration error in the project. But, there is this thread (very short) at the dev forums:
https://developer.apple.com/forums/thread/676210
The person that replied to this question is generally knowledgable on dev related issues.
I saw some people mentioning a link between this particular library conflict and having Homebrew installed. I have no idea if this is a reliable piece of info though.
I have had this type of conflict with some demo projects I've looked at. The error never caused the project not to work, but it is troubling to see.
Are you on the beta of Xcode or the current release?
The reported location of the conflicting libraries could be in a framework, not the actual machine. This would be even more likely to be true in projects with cross-compilation. The other thing that can make it difficult to trace these types of problems is that the library location that's reported could be in a sandbox that you can't directly see unless you take the time to search around through APFS mounts and locations in the caches in ~/Library.
I tried to do a web search for this warning. The problem with getting decent hits is that almost everything is actually unrelated to the warning. The way the command line tools report back warnings in the build process makes it look like this warning is the issue in failed builds where the real issue is totally unrelated. Lots and lots of these types of threads relating to Dart/Flutter projects where the build fails for an unrelated reason but this is the last build warning that is seen before the build fails.
I'd probably ignore the warning if the build is working. If the build is failing, look for a different cause of the failure. You could report the error to Apple like suggested in the one thread -- but I think we all have a feel for what good that would do.
If you really want to track it down or feel like it might eventually cause a problem in your own project, I'd try seeing if it happens for builds for all platform/architectures. This particular library conflict seems to be related to building on M1 based machines, but that could be misleading again. But, that might help narrow down the source of the issue and if it might end up being an actual problem.
If you want to check if the issue is still there using the betas of Xcode, you can have both the production version and the beta installed at the same time. I usually do that in the periods like right now where the transitions are happening. You just have to make sure that any builds for submission are done using the production Xcode. (You also end up needing to play around with xcode-select and related tools to do CLI stuff with the Xcode related tools.)
I think this issue probably isn't related to MacPorts (or Homebrew). It seems like it is an issue with the configuration of certain projects in Xcode but could be an actual issue in the deployments of the libraries on the M1 based Macs. Hard to tell really and the convoluted XML based project files for Xcode don't help in tracking down these issues.
I use MacPorts for installing lots of unix-ish tools and generally don't have problems from using it. I personally don't like Homebrew because of their history of screwing up the filesystem and user permissions. I consider them a security risk. But, I don't think they are a root cause of this problem.
This type of warning has been around forever with Obj-C libraries on the Mac. You can look at it as the Mac's version of DLL Hell or Java's CLASSPATH nightmares. The good thing is that, at least for the system level libraries, it's pretty innocuous in practice.
I have worked at places though with a zero warning policy for code passing QA. This sort of stuff would have been so painful in those places. Then again, I don't think any of them would have put out a product on a consumer grade OS anyway. Makes me wonder what those places are doing today when we pretty much only have consumer grade OS's.
I am interested in hearing what happens when you go to compile one of the projects that failed before. It would be really weird if the root cause were installing Xcode from the App Store instead of the dev download -- not impossible for sure, but really weird.
I'd guess that the install of the CLI tools before the launch of Xcode covered all of the components that it needed, so no extra downloads.
It's going to suck a bit if both MacPorts and Homebrew are having configuration issues. I have pretty much moved back to configuring and compiling most things by hand from source anyway, but MacPorts is pretty convenient for getting things installed fast.
I pretty much only use MacPorts for stuff that I would normally use in BSD or Linux. Given that, configuring and compiling these projects on macOS is pretty much the same as if you do it by hand on Linux or BSD -- hunt down the dependencies and keep everything organized in /usr/local. This usually works out pretty well. I do run into some issues with MacPorts doing compiles outside because the builds there often don't look for dependencies outside of /opt/local. This can be a pain.
If you are wanting some Swift projects that compile easily to look at the structure and test your environment, one source is Apple. If you look at some of the videos in the Developer App, they will often have included projects that work. Game related stuff is a good place to look for Swift things that aren't SwiftUI. Sad truth is though that Apple is making this resource less useful in their moves to make their developer documentation more like standard useless stuff you'd expect out of a web library. Lots of their sample code has been moved in to the archived section of the website and is no longer maintained.
If you want to look at a really simple pretty much all Swift AUv3 project, this is the example I put up exploring the possibility of doing an AUv3 without C++/Objective-C++
https://github.com/NeonSilicon/Demo_Volume_AUv3
The project should build OK. I wouldn't use any of the code in the project to do anything real though. Checkout the README for why I say that
.
There is a bug in the later versions of Xcode where it can't see some of the header files included in the bridging header until after you start a compile. If you see this error in Xcode, try to do the compile anyway and the error should disappear. (I say it's a bug in Xcode because it only does it sometimes and will come and go at different times and different versions of Xcode.)
Regarding all the "Apple-internal errors" popping up all the time while debugging my projects, I've long ago resorted to a custom log function that just prefixes everything with "SevenApp" and I then type "SevenApp" into the "Filter" field in Xcode because honestly, otherwise it's really hard to find MY debug messages among all of Apple's 😂
Many of Apple's templates for project types are a complete mess. Sometimes it makes sense because the missing pieces are really project dependent. But the current AUv3 templates in particular are really confusing -- multiple and redundant files in Swift or Objective-C, some are empty, and the whole result is just confusing.
The project is set to launch the AUv3 in a host app and attach the debugger to the running AUv3 instance that comes up first. So, if you select an AUv3 host from the list of apps and then select my example AU in the host, it should run and the debugger in Xcode should attach to the AU.
The test host I usually use is available here, https://developer.apple.com/documentation/audiotoolbox/audio_unit_v3_plug-ins/incorporating_audio_effects_and_instruments
In recent versions of this you do have to do this weird little thing where you need to select the instruments tab and then go back to the effects tab to get the AU you are trying to test to show up in the list. I have a little bit of a suspicion that this is somehow related to the disappearing AU problem on iOS.
The Ju-X host is a light weight one that'll work too.
Also, if you code-sign the project, you can run it directly in a host on an iOS device if you have one setup for testing. The connection to the running iOS device in the debugger of Xcode is actually pretty nice.
That AU host from Apple I linked to above should run in the simulators too and let you test AU's on the simulator. But, there have been some issues recently with getting it to run correctly in the simulator. If you want to develop AUv3 though, it can help to get this working on the simulator for quick testing.
Yeah, it looks good from the parts I read. Are you wanting to use SwiftUI in particular?
Surprisingly, Apple's documentation on browser based apps isn't totally abysmal.
The main links here are actually helpful,
MacOS:
https://developer.apple.com/documentation/appkit/documents_data_and_pasteboard/developing_a_document-based_app/
iOS:
https://developer.apple.com/documentation/uikit/view_controllers/building_a_document_browser-based_app
https://developer.apple.com/documentation/uikit/view_controllers/building_a_document_browser_app_for_custom_file_formats/
https://developer.apple.com/documentation/uikit/view_controllers/adding_a_document_browser_to_your_app
I don't know if you saw this sample code from Apple for a SwiftUI based version,
https://developer.apple.com/documentation/swiftui/building_a_document-based_app_with_swiftui/
I haven't tested that one at all though because I don't like using SwiftUI. There're some sessions from the last couple of WWDC's that go over using SwiftUI for document based apps that might be useful after you get what you can out of the article you are using now.
This is basically correct, yes.
Yeah, Apple's main structure for most apps is to use the Document Browser structures. This is how GarageBand is structured for example.
Hopefully they'll prove useful for you.
Regarding SwiftUI, it's pretty much Apple's way of making applications that are structured like web apps -- part of the new trend that seems to regard MVC as some sort of evil or something. There are some nice things that come out of using a declarative programming approach like SwiftUI uses, but I personally think it causes problems with structure for large scale or complex programs whereas MVC handles them very well. I've yet to see Apple actually produce any large applications using SwiftUI for example. Also, there are still lots of libraries from UIKit and AppKit that don't have SwiftUI counterparts.
But, it is part of the general trend for developing UI based applications and Apple is positioning it as the way to develop at least many types applications on their platforms. Actually, if you want to do their new Widget stuff, I think you have to use SwiftUI.
@tja - change Team to "none". You won't be able to deploy to any other devices, but should be able to compile and run in the simulator
The developer account is needed because Apple is issuing a signing certificate the way you have it configured. Any issuer is going to want to have some control and visibility into who they're issuing certificates to, or they become meaningless.
Yeh, and you just woke up one morning with the intuitive knowledge of how to do that? C'mon, expecting to not have a learning curve with a new language and IDE is just silly.
You can do this. 
P.S. If you do start signing projects, be aware that the free developer account only allows you to create a limited number of signing certificates per week. My first roadblock with Xcode was I went ahead and started signing Demo and Tutorial projects all over the place, then found I couldn't go any further for about a week. I finally read somewhere that you can re-use a signing certificate, but by then had discovered the "None" developer team workaround.
Yeah, I did this same thing and ended up having to use one project to cram more and more stuff into to learn on before I figured out the "none" thing.
Another thing I did was make the mistake of not having the build system automatically handle signing on my first project. It made going back and forth between dev builds and release builds a total pain. It took me months to figure out how to fix that issue without breaking the project.
Now imagine how exciting all this becomes when you actually DO want to deploy to the App Store, and need "entitlements" from Apple, and have to upgrade your Xcode (12 GB download) AND macOS (another 12 GB download) for every point update of iOS (with the added "bonus" that the latest Xcode never actually supports deploying to a device running the latest iOS (I'm not kidding!)).
Good stuff!