← Back to Guides

Inter-App MIDI-CI Limitations

Understanding the technical limitations of MIDI-CI communication between apps on the same iOS device, and the alternatives available.

The Problem

Many developers want to use MIDI-CI to communicate between their MIDI2Kit-powered app and other apps (like KORG Module Pro) on the same iOS device. Unfortunately, this doesn't work in most cases.

Why It Doesn't Work

The limitation stems from how third-party apps implement MIDI-CI:

1. BLE MIDI Only - Apps like KORG Module Pro only enable MIDI-CI on BLE MIDI interfaces, not on CoreMIDI Virtual Ports
2. No Self-Connection - Bluetooth doesn't allow a device to connect to itself, so BLE MIDI within a single device is impossible
3. Virtual Ports Ignored - Even though CoreMIDI Virtual Ports can technically transmit SysEx messages (including MIDI-CI), most apps don't listen for MIDI-CI on these ports

Tested Scenario

We tested sending MIDI-CI Discovery Inquiry to KORG Module Pro via CoreMIDI Virtual Port:

Test	Result
Virtual Port visible in CoreMIDI	Yes - "Module" destination found
Discovery Inquiry sent	Yes - SysEx transmitted successfully
Discovery Reply received	No - 15 second timeout, no response

Conclusion: KORG Module Pro ignores MIDI-CI messages from Virtual Ports. Its MIDI-CI implementation is tied to the BLE MIDI interface layer only.

Technical Background

iOS Inter-App MIDI

iOS supports inter-app MIDI communication via CoreMIDI Virtual Ports:

• Apps can create Virtual Sources and Destinations
• Other apps can connect to these ports
• Standard MIDI messages (Notes, CC, SysEx) can be exchanged

Why MIDI-CI Is Different

While MIDI-CI technically uses SysEx messages (which can be sent via Virtual Ports), MIDI-CI requires:

• Both ends to actively listen for and respond to Discovery Inquiry
• Proper MUID allocation and management
• Property Exchange capability advertisement

Most third-party apps only implement this on hardware interfaces (USB, BLE MIDI), not on software Virtual Ports.

Working Alternatives

Option 1: Two-Device Setup (Recommended for Real Devices)

Use two iOS devices connected via BLE MIDI:

• Device A: Your MIDI2Kit app
• Device B: KORG Module Pro (or other MIDI-CI device)
• Connect via BLE MIDI
• Full MIDI-CI/PE communication works

Option 2: MockDevice (Recommended for Testing)

Use MIDI2Kit's built-in MockDevice for testing without hardware:

import MIDI2Kit

// Create loopback transport
let (initiator, responder) = LoopbackTransport.createPair()

// Create MockDevice simulating KORG Module Pro
let mockDevice = MockDevice(
    transport: responder,
    preset: .korgModulePro
)
try await mockDevice.start()

// Your app uses initiator transport
let ciManager = CIManager(transport: initiator, ...)
let peManager = PEManager(transport: initiator, ...)

// Full MIDI-CI/PE testing without hardware
await ciManager.startDiscovery()
let response = try await peManager.get("DeviceInfo", from: mockDevice.handle)

Benefits of MockDevice:

• No hardware required
• Fast and deterministic testing
• Simulates various device types
• Customizable responses

Option 3: Two MIDI2Kit Apps (Same Device)

If you control both apps, you can implement MIDI-CI on Virtual Ports:

• Both apps use MIDI2Kit
• Configure CIManager to listen on Virtual Ports
• Full MIDI-CI/PE communication on same device

This only works when both apps are designed to support MIDI-CI on Virtual Ports.

Summary

Scenario	Works?	Notes
MIDI2Kit ↔ KORG Module (Same Device)	No	KORG ignores Virtual Port MIDI-CI
MIDI2Kit ↔ KORG Module (BLE MIDI)	Yes	Requires two devices
MIDI2Kit ↔ MockDevice (Same App)	Yes	Recommended for testing
MIDI2Kit ↔ MIDI2Kit App (Same Device)	Yes	Both apps must use MIDI2Kit

Recommendations

1. For Development/Testing: Use MockDevice with LoopbackTransport
2. For Real Device Testing: Use two-device BLE MIDI setup
3. For Production: Support both BLE MIDI and USB MIDI interfaces for maximum compatibility