Concerns about App Review risk for vendor-specific device protocol that reuses Matter-derived components internally

My team is evaluating an iOS companion app for our own network-connected device, and we want to understand whether the planned architecture would likely create an App Review problem under Guideline 2.5.17.

Our situation is:

• We are building our own device and our own companion app.
• We do not intend to market the device as a Matter-certified device initially.
• We do not intend to support Apple Home or broad third-party Matter ecosystem interoperability in the first release.
• We are under a tight schedule and are considering reusing Matter/CSA-derived libraries, data models, and protocol concepts internally to reduce engineering effort and move faster toward eventual certification.

Our current understanding is that there are already many iOS apps that communicate with LAN-connected devices using proprietary protocols, so our initial assumption is that a vendor-specific local-network device workflow should generally be acceptable. The point we are trying to clarify is whether that changes if the implementation under the hood is based in part on Matter-derived components.

The idea we are considering is:

1. Ship an initial release where the device and app use a vendor-specific onboarding and communication flow.
2. The implementation would likely use something based on connectedhomeip under the hood, but the shipped protocol would be intentionally modified so that it is proprietary in practice and not interoperable with the broader Matter ecosystem.
3. In other words, the device would not present as a normal Matter accessory, and other Matter controllers/devices would not be able to communicate with it as if it were a standard Matter device.
4. Later, after full Matter certification work is complete, we would deliver an OTA update to enable proper Matter ecosystem interoperability.

The question we are trying to answer is whether the mobile app itself would likely be acceptable on the App Store during that first phase.

More specifically:

1. If our app communicates only with our own device and not with Apple Home or third-party Matter controllers, but internally reuses Matter-derived software/protocol components, would Apple still likely consider that an app that “supports Matter” for purposes of Guideline 2.5.17?

2. If the app includes something based on connectedhomeip or a modified subset of such a library, but the shipped device/app behavior is intentionally not interoperable with the general Matter ecosystem, is that still likely to be treated as use of a non-Apple Matter software component that must already be CSA-certified for iOS?

3. From App Review’s point of view, what matters most here:

   • whether Apple’s Matter pairing framework is used,
   • whether the product is presented to users as a Matter accessory,
   • whether the protocol remains interoperable with third-party Matter ecosystems,
   • or simply whether Matter-derived software/components are included in the app at all?

4. Is there a meaningful App Review distinction between:

   • a proprietary device protocol designed entirely in-house, and
   • a vendor-specific protocol that reuses Matter-derived transport/session/data-model components internally but is intentionally incompatible with standard Matter interoperability in the shipped product?

We are trying to understand whether this staged approach is fundamentally incompatible with App Review, or whether it can be acceptable as a vendor-specific device workflow during development toward full certification.