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 Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

What's the story with iOS apps available for mac on M1?

2»

Comments

  • knewspeakknewspeak

    @krassmann said:
    .

    @j_liljedahl said:

    @brambos said:

    @NeuM said:

    @kidslow said:

    @NeuM said:
    And I sure wish more developers would at least make an effort to "click the button" in Xcode to allow their apps to function on macOS, even if not in a completely clean cross platform way. I have a ton of synths and effects I'd love to be able to use on desktop.

    So that's the secret, Apple added a button in Xcode to make it seamless? Any way to know which apps have the functionality before purchasing or is there a list or some clue inside the App store? Seems like a USP for developers and they'd want to advertise it.

    Of course I’m drastically simplifying things, but Apple has attempted to make the process of getting iOS apps onto macOS simpler. I’m sure some developers could weigh in on how “easy” or difficult this is in reality.

    It's easier than a complete port. It's infinitely more work than "ticking a checkbox". Also, for me the hesitation is the potentially much higher support load (answering emails and solving problems with more different hosts and OS-update related misery) when adding a new platform into the equation.

    Indeed. Also, for an app like AUM there's a lot of things that needs rewrite and conditional code, because while the checkbox in xcode makes it easy to port most UI stuff, it's not the same with CoreAudio. Things doesn't work the same way, there's no RemoteIO AU and accessing multi-channel interfaces is not the same, etc.

    That’s very interesting and surprising for me. From a naïve point of view I would expect that to be the other way round. I see lots of differences in the UI between iOS and MacOS, last but not least the touch vs. mouse operation. I expected that an interface like CoreAudio would be much more similar if not identical because I see no reason why audio should be different on a mobile device. Is iOS CoreAudio a subset of its MacOS counterpart or are there even conceptual differences?

    For an AUv3 plugin it's easier, but it can be a lot of work making the plugin pass auval. We don't have anything like auval on iOS, so many plugins that happens to work on iOS will not pass auval because it tests things and configurations not commonly used by hosts on iOS.

    All this combined with the additional support load is the reason I'm going to make any Mac versions of my apps and plugins as separate purchases.

    The good thing about Mac Catalyst is that it works for both M1 and Intel macs.

    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance. The only thing is that they don’t work as AUs in Ableton for whatever reason.

    AUs don’t work in Ableton they’d need a VST wrapper I believe.

  • kidslowkidslow
    edited December 2021

    @krassmann said:
    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance.

    Maybe it's not an M1 thing but a Big Sur and up thing then?

  • j_liljedahlj_liljedahl

    @krassmann said:
    .

    @j_liljedahl said:

    @brambos said:

    @NeuM said:

    @kidslow said:

    @NeuM said:
    And I sure wish more developers would at least make an effort to "click the button" in Xcode to allow their apps to function on macOS, even if not in a completely clean cross platform way. I have a ton of synths and effects I'd love to be able to use on desktop.

    So that's the secret, Apple added a button in Xcode to make it seamless? Any way to know which apps have the functionality before purchasing or is there a list or some clue inside the App store? Seems like a USP for developers and they'd want to advertise it.

    Of course I’m drastically simplifying things, but Apple has attempted to make the process of getting iOS apps onto macOS simpler. I’m sure some developers could weigh in on how “easy” or difficult this is in reality.

    It's easier than a complete port. It's infinitely more work than "ticking a checkbox". Also, for me the hesitation is the potentially much higher support load (answering emails and solving problems with more different hosts and OS-update related misery) when adding a new platform into the equation.

    Indeed. Also, for an app like AUM there's a lot of things that needs rewrite and conditional code, because while the checkbox in xcode makes it easy to port most UI stuff, it's not the same with CoreAudio. Things doesn't work the same way, there's no RemoteIO AU and accessing multi-channel interfaces is not the same, etc.

    That’s very interesting and surprising for me. From a naïve point of view I would expect that to be the other way round. I see lots of differences in the UI between iOS and MacOS, last but not least the touch vs. mouse operation. I expected that an interface like CoreAudio would be much more similar if not identical because I see no reason why audio should be different on a mobile device. Is iOS CoreAudio a subset of its MacOS counterpart or are there even conceptual differences?

    The API is exactly the same, except there's no IAA on Mac, and until Big Sur there was no function to retrieve the icon for AUv3 plugins. But the API behave differently when it comes to managing connected audio interfaces and querying their channels etc.

    And yes, there is work to do with UI as well regarding touch vs mouse, especially for multi-tap gestures and stuff like that.

  • seonnthaproducerseonnthaproducer
    1. The two Moog apps worked well during my tests. Animoog Z, and Model 15
    2. Did some tests on SEGMENTS and EG Pulse. Worked well although I did have some weird GarageBand crashes on Mac M1.


    3. Documents by Readdle, Pythonista worked well.
    4. Koala Sampler for iOS also works as well
    5. Drambo was great to test

    That said, out of the hundreds of apps I have, only 20 can be installed, and these were the notable ones.

  • krassmannkrassmann

    @knewspeak said:

    @krassmann said:
    .

    @j_liljedahl said:

    @brambos said:

    @NeuM said:

    @kidslow said:

    @NeuM said:
    And I sure wish more developers would at least make an effort to "click the button" in Xcode to allow their apps to function on macOS, even if not in a completely clean cross platform way. I have a ton of synths and effects I'd love to be able to use on desktop.

    So that's the secret, Apple added a button in Xcode to make it seamless? Any way to know which apps have the functionality before purchasing or is there a list or some clue inside the App store? Seems like a USP for developers and they'd want to advertise it.

    Of course I’m drastically simplifying things, but Apple has attempted to make the process of getting iOS apps onto macOS simpler. I’m sure some developers could weigh in on how “easy” or difficult this is in reality.

    It's easier than a complete port. It's infinitely more work than "ticking a checkbox". Also, for me the hesitation is the potentially much higher support load (answering emails and solving problems with more different hosts and OS-update related misery) when adding a new platform into the equation.

    Indeed. Also, for an app like AUM there's a lot of things that needs rewrite and conditional code, because while the checkbox in xcode makes it easy to port most UI stuff, it's not the same with CoreAudio. Things doesn't work the same way, there's no RemoteIO AU and accessing multi-channel interfaces is not the same, etc.

    That’s very interesting and surprising for me. From a naïve point of view I would expect that to be the other way round. I see lots of differences in the UI between iOS and MacOS, last but not least the touch vs. mouse operation. I expected that an interface like CoreAudio would be much more similar if not identical because I see no reason why audio should be different on a mobile device. Is iOS CoreAudio a subset of its MacOS counterpart or are there even conceptual differences?

    For an AUv3 plugin it's easier, but it can be a lot of work making the plugin pass auval. We don't have anything like auval on iOS, so many plugins that happens to work on iOS will not pass auval because it tests things and configurations not commonly used by hosts on iOS.

    All this combined with the additional support load is the reason I'm going to make any Mac versions of my apps and plugins as separate purchases.

    The good thing about Mac Catalyst is that it works for both M1 and Intel macs.

    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance. The only thing is that they don’t work as AUs in Ableton for whatever reason.

    AUs don’t work in Ableton they’d need a VST wrapper I believe.

    I have Ableton Live Lite 11 under Big Sur and AU plugins are working

  • krassmannkrassmann

    @kidslow said:

    @krassmann said:
    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance.

    Maybe it's not an M1 thing but a Big Sur and up thing then?

    AFAIK if developers use Mac Catalyst the app is universal and they can also generate an Intel binary for MacOS.

  • krassmannkrassmann

    @j_liljedahl said:

    @krassmann said:
    .

    @j_liljedahl said:

    @brambos said:

    @NeuM said:

    @kidslow said:

    @NeuM said:
    And I sure wish more developers would at least make an effort to "click the button" in Xcode to allow their apps to function on macOS, even if not in a completely clean cross platform way. I have a ton of synths and effects I'd love to be able to use on desktop.

    So that's the secret, Apple added a button in Xcode to make it seamless? Any way to know which apps have the functionality before purchasing or is there a list or some clue inside the App store? Seems like a USP for developers and they'd want to advertise it.

    Of course I’m drastically simplifying things, but Apple has attempted to make the process of getting iOS apps onto macOS simpler. I’m sure some developers could weigh in on how “easy” or difficult this is in reality.

    It's easier than a complete port. It's infinitely more work than "ticking a checkbox". Also, for me the hesitation is the potentially much higher support load (answering emails and solving problems with more different hosts and OS-update related misery) when adding a new platform into the equation.

    Indeed. Also, for an app like AUM there's a lot of things that needs rewrite and conditional code, because while the checkbox in xcode makes it easy to port most UI stuff, it's not the same with CoreAudio. Things doesn't work the same way, there's no RemoteIO AU and accessing multi-channel interfaces is not the same, etc.

    That’s very interesting and surprising for me. From a naïve point of view I would expect that to be the other way round. I see lots of differences in the UI between iOS and MacOS, last but not least the touch vs. mouse operation. I expected that an interface like CoreAudio would be much more similar if not identical because I see no reason why audio should be different on a mobile device. Is iOS CoreAudio a subset of its MacOS counterpart or are there even conceptual differences?

    The API is exactly the same, except there's no IAA on Mac, and until Big Sur there was no function to retrieve the icon for AUv3 plugins. But the API behave differently when it comes to managing connected audio interfaces and querying their channels etc.

    And yes, there is work to do with UI as well regarding touch vs mouse, especially for multi-tap gestures and stuff like that.

    Alright, very good. Given the obvious strategy of Apple to enable cross platform development it would have been hilarious to have two different CoreAudio APIs. It's a shame they behave differently in certain areas. Apple should address this.

  • NeonSiliconNeonSilicon

    @krassmann said:

    @knewspeak said:

    @krassmann said:
    .

    @j_liljedahl said:

    @brambos said:

    @NeuM said:

    @kidslow said:

    @NeuM said:
    And I sure wish more developers would at least make an effort to "click the button" in Xcode to allow their apps to function on macOS, even if not in a completely clean cross platform way. I have a ton of synths and effects I'd love to be able to use on desktop.

    So that's the secret, Apple added a button in Xcode to make it seamless? Any way to know which apps have the functionality before purchasing or is there a list or some clue inside the App store? Seems like a USP for developers and they'd want to advertise it.

    Of course I’m drastically simplifying things, but Apple has attempted to make the process of getting iOS apps onto macOS simpler. I’m sure some developers could weigh in on how “easy” or difficult this is in reality.

    It's easier than a complete port. It's infinitely more work than "ticking a checkbox". Also, for me the hesitation is the potentially much higher support load (answering emails and solving problems with more different hosts and OS-update related misery) when adding a new platform into the equation.

    Indeed. Also, for an app like AUM there's a lot of things that needs rewrite and conditional code, because while the checkbox in xcode makes it easy to port most UI stuff, it's not the same with CoreAudio. Things doesn't work the same way, there's no RemoteIO AU and accessing multi-channel interfaces is not the same, etc.

    That’s very interesting and surprising for me. From a naïve point of view I would expect that to be the other way round. I see lots of differences in the UI between iOS and MacOS, last but not least the touch vs. mouse operation. I expected that an interface like CoreAudio would be much more similar if not identical because I see no reason why audio should be different on a mobile device. Is iOS CoreAudio a subset of its MacOS counterpart or are there even conceptual differences?

    For an AUv3 plugin it's easier, but it can be a lot of work making the plugin pass auval. We don't have anything like auval on iOS, so many plugins that happens to work on iOS will not pass auval because it tests things and configurations not commonly used by hosts on iOS.

    All this combined with the additional support load is the reason I'm going to make any Mac versions of my apps and plugins as separate purchases.

    The good thing about Mac Catalyst is that it works for both M1 and Intel macs.

    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance. The only thing is that they don’t work as AUs in Ableton for whatever reason.

    AUs don’t work in Ableton they’d need a VST wrapper I believe.

    I have Ableton Live Lite 11 under Big Sur and AU plugins are working

    That's good to finally hear, but are they v2 AU's only?

    @krassmann said:

    @kidslow said:

    @krassmann said:
    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance.

    Maybe it's not an M1 thing but a Big Sur and up thing then?

    AFAIK if developers use Mac Catalyst the app is universal and they can also generate an Intel binary for MacOS.

    Yes, Mac Catalyst apps can be booth Intel and Arm compatible. That's a big advantage to using Mac Catalyst over simply having Apple make the iOS app available on the Mac.

  • krassmannkrassmann

    @NeonSilicon said:

    @krassmann said:

    @knewspeak said:

    @krassmann said:
    .

    @j_liljedahl said:

    @brambos said:

    @NeuM said:

    @kidslow said:

    @NeuM said:
    And I sure wish more developers would at least make an effort to "click the button" in Xcode to allow their apps to function on macOS, even if not in a completely clean cross platform way. I have a ton of synths and effects I'd love to be able to use on desktop.

    So that's the secret, Apple added a button in Xcode to make it seamless? Any way to know which apps have the functionality before purchasing or is there a list or some clue inside the App store? Seems like a USP for developers and they'd want to advertise it.

    Of course I’m drastically simplifying things, but Apple has attempted to make the process of getting iOS apps onto macOS simpler. I’m sure some developers could weigh in on how “easy” or difficult this is in reality.

    It's easier than a complete port. It's infinitely more work than "ticking a checkbox". Also, for me the hesitation is the potentially much higher support load (answering emails and solving problems with more different hosts and OS-update related misery) when adding a new platform into the equation.

    Indeed. Also, for an app like AUM there's a lot of things that needs rewrite and conditional code, because while the checkbox in xcode makes it easy to port most UI stuff, it's not the same with CoreAudio. Things doesn't work the same way, there's no RemoteIO AU and accessing multi-channel interfaces is not the same, etc.

    That’s very interesting and surprising for me. From a naïve point of view I would expect that to be the other way round. I see lots of differences in the UI between iOS and MacOS, last but not least the touch vs. mouse operation. I expected that an interface like CoreAudio would be much more similar if not identical because I see no reason why audio should be different on a mobile device. Is iOS CoreAudio a subset of its MacOS counterpart or are there even conceptual differences?

    For an AUv3 plugin it's easier, but it can be a lot of work making the plugin pass auval. We don't have anything like auval on iOS, so many plugins that happens to work on iOS will not pass auval because it tests things and configurations not commonly used by hosts on iOS.

    All this combined with the additional support load is the reason I'm going to make any Mac versions of my apps and plugins as separate purchases.

    The good thing about Mac Catalyst is that it works for both M1 and Intel macs.

    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance. The only thing is that they don’t work as AUs in Ableton for whatever reason.

    AUs don’t work in Ableton they’d need a VST wrapper I believe.

    I have Ableton Live Lite 11 under Big Sur and AU plugins are working

    That's good to finally hear, but are they v2 AU's only?

    I think so. According to Ableton Live is not supporting v3:

    https://help.ableton.com/hc/en-us/articles/209769405-Supported-Plug-in-formats

    While looking at my Mac plugins I noticed something strange about the Moog apps. They appear in Ableton in the plugin list and I have it configured to only use AUs. But looking into /Library/Audio/Plug-Ins/Components or ~/Library/Audio/Plug-Ins/Components I cannot see them. Moog and J_No Chorus are the only AUs listed in Ableton that are not appearing in the Library directories and are also not working in Ableton. Both had been installed via Mac appstore - all other plugins I have were installed by an installer. Strange... there must be another way to register AUs that seems to happen when installed via appstore but it looks that it doesn't work for Ableton.

    @krassmann said:

    @kidslow said:

    @krassmann said:
    I can see a growing number of original iOS apps that are n the Mac appstore on my Intel Mac and look exactly the same. Moog apps and the fingerlab synths for instance.

    Maybe it's not an M1 thing but a Big Sur and up thing then?

    AFAIK if developers use Mac Catalyst the app is universal and they can also generate an Intel binary for MacOS.

    Yes, Mac Catalyst apps can be booth Intel and Arm compatible. That's a big advantage to using Mac Catalyst over simply having Apple make the iOS app available on the Mac.

  • krassmannkrassmann

    Strange... Moog AUs not stored at the canonical location

  • uncledaveuncledave

    @krassmann . On my Win10 computer, apps from the MS Store are installed in a shadow directory tree buried quite deep in the system. This differs from apps installed by the conventional installers, which are pretty easy to find. Not sure why this should be the case; perhaps because these apps are managed by the Store. If the MacOS philosophy is anything like this, you might need to dig a little deeper. Maybe try searching for the app names?

  • [Deleted User][Deleted User]
    The user and all related content has been deleted.
  • j_liljedahlj_liljedahl

    @krassmann said:
    Strange... Moog AUs not stored at the canonical location

    AUv3's are stored in their container apps, not in a special location. That's why they need to be registered, so that MacOS can find them.

  • krassmannkrassmann

    @j_liljedahl said:

    @krassmann said:
    Strange... Moog AUs not stored at the canonical location

    AUv3's are stored in their container apps, not in a special location. That's why they need to be registered, so that MacOS can find them.

    Ah, slowly it all makes sense. The Moog AUs are probably AUv3. Ableton does not support AUv3 but doesn't filter them out. So they are listed but don't work.

  • uncledaveuncledave

    @tja said:

    @knewspeak said:

    @MobileMusic said:
    As long as the Macs do not have touch screens, it is silly to have touch-based iOS apps on Macs.

    The harder problem would be the reverse, desktop apps on a touch screen device, UI rewrite.

    I never ever understood this.

    Shouldn't that be totally transparent?

    On iPad, just map the left-button mouse click to a "touch" and map the right-button mouse click to "press-and-hold".

    And finish.

    This should simply be done in iPadOS and all iPad Apps would work with a mouse.
    At least, I can't see why this would be a problem and why App developers need to change anything...

    And yes, this could work the other way around as well. Just map a touch to a "left-click" mouse event and a press-and-hold to a "right-click" mouse event.

    Anybody knows and can explain?

    You don't have hover on a touch screen; any touch triggers an action. So, for example, once you've opened a popup menu, you cannot slide down it and view submenus. I'm sure there are other limitations as well.

  • NeonSiliconNeonSilicon

    @krassmann said:

    @j_liljedahl said:

    @krassmann said:
    Strange... Moog AUs not stored at the canonical location

    AUv3's are stored in their container apps, not in a special location. That's why they need to be registered, so that MacOS can find them.

    Ah, slowly it all makes sense. The Moog AUs are probably AUv3. Ableton does not support AUv3 but doesn't filter them out. So they are listed but don't work.

    Yeah, that would most likely be the cause. You can see what type of AU a plugin is by looking in the plugin manager in Logic or MainStage.

    It's a pretty weird decision to me to finally support AU's and then only support the format that is on the way out. Apple could probably help force this situation if they would make their own Logic plugins AUv3 and available to other hosts if you owned Logic.

  • NeonSiliconNeonSilicon

    @tja said:

    @knewspeak said:

    @MobileMusic said:
    As long as the Macs do not have touch screens, it is silly to have touch-based iOS apps on Macs.

    The harder problem would be the reverse, desktop apps on a touch screen device, UI rewrite.

    I never ever understood this.

    Shouldn't that be totally transparent?

    On iPad, just map the left-button mouse click to a "touch" and map the right-button mouse click to "press-and-hold".

    And finish.

    This should simply be done in iPadOS and all iPad Apps would work with a mouse.
    At least, I can't see why this would be a problem and why App developers need to change anything...

    And yes, this could work the other way around as well. Just map a touch to a "left-click" mouse event and a press-and-hold to a "right-click" mouse event.

    Anybody knows and can explain?

    I think choosing what to map where is more dependent on the particular UI you are porting.

    Tap and hold on the iPad keyboard/trackpad is already mapped to click-and-hold. Left and right mouse buttons aren't as easy and clean as you want either. The trackpad situation brings in two finger tap and option-tap and ctrl-tap. iPadOS does some mapping for secondary click actions, but they aren't completely mapped sensibly if you ask me. This carries over somewhat to Mac Catalyst, so there are things you need to take control of and re-map to more sensible things for your UI.

    The big issues I see in moving from macOS to iOS is in the UI scale and how you interact with keyboard input. This is a major rework to get done well. Some of the AU's I have on iOS are ports from older AU's I did for the Mac long ago. The UI's on these are 100% rewritten. CuSnP is a port of a plugin I did called xResonance. Whole bunches of xResonance was based around text input of the tuning of the resonator frequency. Text input for an AU on iOS has lots of issues, so I needed to change the entire UI to make a system that allowed users to input frequency relationships in a somewhat easy manner. xResonance had a text box per string and all the mapping was done interpreting text input like "4/3 C4." the iOS version of that maps to an entire extra input view. I'm basically experimenting with the way UI works in a touch based setting, so other apps might well choose to do this with text input, but the choice isn't really a simple and easy thing.

    UI scale is really important. Probably the biggest issue I see with desktop plugins (or other apps) ported to iOS is leaving the size of the controls mouse/cursor appropriate. This just sucks UI wise on iOS.

  • daktidakti
    edited December 2021

    @kidslow said:
    Is anyone aware of a list of apps that are available like this?

    Here is a list of most iOS and iPadOS apps. In "R" column there is mark wheater is compatible with M1 Macs.

    https://docs.google.com/spreadsheets/d/1vydiVIIZR48AFiRcfANzmRnec-eZ-6yiE5C21ztkU6A/edit#gid=580256781

    List of apps with M1 cross compatible from that spreadsheet effective 03 Dec 2021:

    Paid:

    • Animoog Z Synthesizer - (Moog Music Inc)
    • Minimoog Model D Synthesizer - (Moog Music Inc)
    • Model 15 Modular Synthesizer - (Moog Music Inc)
    • Drambo - (BeepStreet)
    • Sunrizer synth - (BeepStreet)
    • Zeeon synth - (BeepStreet)
    • SimplyFlange - (B-Ray Software)
    • SimplyLowPass - (B-Ray Software)
    • SimplyPhaser - (B-Ray Software)
    • SimplyTremolo - (B-Ray Software)
    • VADrum2 - (Ryo Togawa)
    • VAMono - (Ryo Togawa)
    • VOLT Synth - (Kai Aras)
    • miRack - (mifki Limited)
    • ZOA — Living MIDI Sequencer - (Ryan Robinson)
    • AddStation - (Harry Gohs)
    • FL Studio Mobile - (Image Line Software)
    • Wotja Pro 21: Generative Music - (Intermorphic Ltd.)

    Free (some with paid IAP *)

    • Flynth - (Fingerlab) *
    • iPhilicorda - (Fingerlab) *
    • Mynth - (Fingerlab) *
    • PolyWave - (Fingerlab) *
    • AmpStamp - (The Musicology Group, Inc.) *
    • Deep Wave - Spectrogram - (Pham Thang)
    • GyroVibe - (Neon Silicon)
    • Intensifier AUv3 - (Evan Murray)
    • PhaseDelayArray - (Neon Silicon)
    • Wavebox - (Luis Rivas)
  • kidslowkidslow

    @dakti said:
    Here is a list of most iOS and iPadOS apps. In "R" column there is mark wheater is compatible with M1 Macs.

    Cool. Thanks for that.

  • [Deleted User][Deleted User]
    The user and all related content has been deleted.
  • piano39piano39

    Is there any updated list of IOS apps that run on Macs with M1, M2 or M3 chips?

  • brambosbrambos

    I really hate how Apple have created the perception that making an iOS app work on MacOS is a matter of checking a box and launching the app 10 minutes later.

    I get way too many emails almost demanding I make my apps available on MacOS because it's so easy anyway.

    /rant over.

  • klownshedklownshed

    @brambos said:
    I really hate how Apple have created the perception that making an iOS app work on MacOS is a matter of checking a box and launching the app 10 minutes later.

    I get way too many emails almost demanding I make my apps available on MacOS because it's so easy anyway.

    /rant over.

    Yeah sorry about that but I figure if I keep emailing you, you’re more likely to check that box :lol:

  • GrimLuckyGrimLucky

    @brambos said:
    I really hate how Apple have created the perception that making an iOS app work on MacOS is a matter of checking a box and launching the app 10 minutes later.

    I get way too many emails almost demanding I make my apps available on MacOS because it's so easy anyway.

    /rant over.

    So…... about Mosaic on Logic desktop 😁

    /just getting my coat

  • brambosbrambos

    @klownshed said:

    @brambos said:
    I really hate how Apple have created the perception that making an iOS app work on MacOS is a matter of checking a box and launching the app 10 minutes later.

    I get way too many emails almost demanding I make my apps available on MacOS because it's so easy anyway.

    /rant over.

    Yeah sorry about that but I figure if I keep emailing you, you’re more likely to check that box :lol:

    :D <3

  • LuxthorLuxthor

    @tja said:

    @knewspeak said:

    @MobileMusic said:
    As long as the Macs do not have touch screens, it is silly to have touch-based iOS apps on Macs.

    The harder problem would be the reverse, desktop apps on a touch screen device, UI rewrite.

    I never ever understood this.

    Shouldn't that be totally transparent?

    On iPad, just map the left-button mouse click to a "touch" and map the right-button mouse click to "press-and-hold".

    And finish.

    This should simply be done in iPadOS and all iPad Apps would work with a mouse.
    At least, I can't see why this would be a problem and why App developers need to change anything...

    And yes, this could work the other way around as well. Just map a touch to a "left-click" mouse event and a press-and-hold to a "right-click" mouse event.

    Anybody knows and can explain?

    You don’t have a cursor or cursor hover, it’s hard to draw or select anything with two, three, or more fingers on the surface (cursor positioning). Undefined tap region size (different sizes of fingers), it will never be precise like an Apple Pencil or mouse. There are probably more, those few are from the top of my head. 😅

Sign In or Register to comment.

© Vanilla Keystone Theme 2024