The difference only shows up once the hierarchy has more than one level, which happens as soon as someone creates a Blueprint child of a subsystem written in C++.

I covered the lifecycle contract and where each collection starts in a separate post: Subsystem and manager actor lifecycles. Here, I’m focusing on one specific part: the loop that picks the classes.

A subclass does not replace its parent

The collection gathers derived classes in a single call and runs every one of them through the same procedure (Engine/Private/Subsystems/SubsystemCollection.cpp:209):

TArray<UClass*> SubsystemClasses;
GetDerivedClasses(BaseType, SubsystemClasses, true);

for (UClass* SubsystemClass : SubsystemClasses)
{
    AddAndInitializeSubsystem(SubsystemClass);
}

There is no selection of the most-derived class here, no collapsing of the hierarchy, no rule that the child wins over the parent. The question is asked separately of each entry’s own CDO (SubsystemCollection.cpp:331):

const USubsystem* CDO = SubsystemClass->GetDefaultObject<USubsystem>();
if (CDO->ShouldCreateSubsystem(Outer))
{
    USubsystem* Subsystem = NewObject<USubsystem>(Outer, SubsystemClass);
    SubsystemMap.Add(SubsystemClass, Subsystem);
    // ...
}

The consequence is straightforward and easy to miss: a Blueprint child of a C++ class joins the parent as a second, independent instance. The base implementation returns true (Subsystem.h:61), so if nobody has overridden the method, two instances live in the collection. One of the C++ class, one of the Blueprint class. Both have run Initialize, both carry their own state, and neither knows about the other.

Two filters run before that question is asked. The first rejects abstract classes (:318), the second rejects non-authoritative ones (:324):

// Do not create instances of classes that aren't authoritative.
if (SubsystemClass->GetAuthoritativeClass() != SubsystemClass)
{
    return nullptr;
}

The second one says something about intent. GetAuthoritativeClass filters out the intermediate classes produced when Blueprints are recompiled, which means Epic hardened this path for Blueprint classes. A Blueprint subsystem is a scenario the engine anticipates.

The switch: false in C++, true in Blueprint

The question is asked separately of every CDO, and Blueprint defaults live on the CDO of their class. The same flag can therefore hold a different value at each level of the hierarchy, which turns it into a switch between implementation layers:

UCLASS(Blueprintable)
class MYGAME_API UMySubsystem : public UGameInstanceSubsystem
{
    GENERATED_BODY()

protected:
    /** Read from the CDO only - set to true in the Blueprint child that implements this. */
    UPROPERTY(EditDefaultsOnly, Category = "Config")
    bool bShouldCreateSubsystem = false;

    virtual bool ShouldCreateSubsystem(UObject* Outer) const override
    {
        return Super::ShouldCreateSubsystem(Outer) && bShouldCreateSubsystem;
    }
};

With false on the C++ side and true in the Blueprint class defaults, exactly one instance ends up in the collection. The C++ class becomes a skeleton: it defines the interface, the BlueprintImplementableEvent declarations, and everything Blueprint cannot declare on its own, while the implementation lives one level below.

This works because ShouldCreateSubsystem runs on the CDO before an instance exists, which means it runs on the object that holds the default values stored in the Blueprint asset. That is also why the flag is marked EditDefaultsOnly. The value is read from the defaults and nowhere else, so per-instance editing changes nothing.

GetSubsystem<T>() finds the child anyway

Instances live in a TMap<UClass*, USubsystem*> keyed by the concrete class. The natural conclusion is that querying for the base class will not find an instance of a derived one, and that conclusion is wrong. GetSubsystemInternal has a fallback (SubsystemCollection.cpp:66):

USubsystem* SystemPtr = SubsystemMap.FindRef(SubsystemClass);

if (SystemPtr)
{
    return SystemPtr;
}
else
{
    const FSubsystemArray& SystemPtrs = FindAndPopulateSubsystemArrayInternal(SubsystemClass);
    if (SystemPtrs.Subsystems.Num() > 0)
    {
        return SystemPtrs.Subsystems[0];
    }
}

A miss in the map triggers an IsChildOf sweep and returns the first hit. So GetSubsystem<UMySubsystem>() with the base class as the parameter returns the Blueprint child instance, even though nothing is stored under the base class key.

Without that fallback the switch would make no sense. Every piece of C++ that queries the subsystem by its own base class would stop seeing it the moment the implementation moved into Blueprint.

Listing every instance at once takes a separate accessor. In 5.7 it is called GetSubsystemArrayCopy and returns by value, both on the collection itself (Public/Subsystems/SubsystemCollection.h:139) and on the UGameInstance wrapper (Classes/Engine/GameInstance.h:463).

The flagless variant: yielding to subclasses

The flag has one unpleasant property. When the Blueprint child is gone, whether it was deleted, moved, or simply never loaded in time, false on the C++ side means nothing is created. The subsystem disappears entirely, including the part that was written in C++ and had nothing to do with Blueprint.

The condition can be phrased differently: let the class step aside, provided there is someone to step aside for.

bool UMySubsystem::ShouldCreateSubsystem(UObject* Outer) const
{
    if (!Super::ShouldCreateSubsystem(Outer))
    {
        return false;
    }

    /// @Note: The collection instantiates every non-abstract subclass, so a Blueprint child
    ///        would live alongside this one. Yield so that only the most-derived class is created.
    TArray<UClass*> DerivedClasses;
    GetDerivedClasses(GetClass(), DerivedClasses, /*bRecursive*/ true);
    return DerivedClasses.Num() == 0;
}

In the normal case the outcome is the same, since a child exists and the parent steps aside. The failure looks different though: a missing child leaves a working C++ instance instead of an empty slot. There is also no flag to forget to set in a new Blueprint’s defaults.

I use this variant in a production subsystem, and I have tested it in PIE. With the Blueprint child present, exactly one instance is alive; with the child removed, the C++ instance is. I have not tested it in a packaged build, so that behavior remains an inference from the mechanism rather than an observed result.

There are two limits, and both follow directly from this implementation.

Two children mean two instances. Each of them sees zero descendants and each concludes that it is the most-derived one. This case cannot be resolved inside the method, which leaves a convention: exactly one Blueprint child per class.

A single permanently loaded C++ subclass disables the base class for good. A test class in an Editor module is enough. It is compiled, so it sits in memory from startup, so the parent yields to it in every editor session. In practice this means a test module must not derive from such a subsystem, and the test double has to be built on a plain UObject acting as a listener. This trap is worse than two Blueprint children, because nothing about it is visible in the assets. It lives in test code that nobody associates with runtime.

Common mistakes

The last of those cannot be reproduced in the editor. It only surfaces in a packaged build.

Verification

The number and classes of live instances, in one console command:

obj list class=MySubsystem

A query for the base class covers derived classes, so it shows the parent and the children at once, broken down by class. Two rows instead of one reveal the duplication described in the table above; a row for a _C class means the switch worked and the Blueprint implementation is the one running.

Each CDO decision is in the log once the category’s log level is raised:

-LogCmds="LogSubsystemCollection VeryVerbose"

LogSubsystemCollection: VeryVerbose: Subsystem does not exist, but CDO choose to not create (MySubsystem)

That line means the class was on the list and refused. Its absence, together with a missing instance, means something entirely different: the class was not on the list, so nobody asked it. Telling those two states apart is the only way to distinguish a working switch from a class that never loaded. At the default log level both of them look like silence, which is why the category’s log level has to be raised first.

What FTickableGameObject is

FTickableGameObject is a plain C++ class from Tickable.h that you inherit from alongside UObject. Its constructor adds this to a pending queue (Tickable.cpp:133-145), and the object only moves into the real array at the next tick pass (Tickable.cpp:67-95). The destructor removes it from that array (Tickable.cpp:147-152), and the engine walks the array once per frame (Tickable.cpp:167-208). This is a separate track running alongside the FTickFunction machinery that actors and components use. It is not part of it.

The upside is that the object does not have to be in a world, does not have to be spawned, and has no transform. The price is that it also gets none of what the other track gives actors: no tick groups, no AddTickPrerequisiteActor, no TickInterval. The entire class declaration (Tickable.h:134-210) does not contain a single one of them. You either give up all three or build them by hand.

For an object tied to a world, the call sits in UWorld::Tick (LevelTick.cpp:1792), after TG_PostPhysics (LevelTick.cpp:1749) but before TG_PostUpdateWork (LevelTick.cpp:1848). An actor ticking in TG_PostUpdateWork sees the state this tick has already produced. An object with no world lands somewhere else: it ticks only after the loop over all worlds. The engine says so outright in the comment on the method (Tickable.h:183), and the call itself sits in GameEngine.cpp:1947.

When to reach for this, and when not to

Does this have to be an actor? If the object needs a transform, collision, replication, placement in a level, or tick groups, the answer is “actor” and the rest of this post does not apply. None of those can be bolted onto FTickableGameObject.

Is the logic per-frame or event-driven? If it comes down to “in three seconds” or “every half second” and nothing in between, that is FTimerManager, not a tick. Polling state sixty times a second to respond once is a cost with no return.

Should the object live exactly as long as the world? If so, the right answer is almost always UTickableWorldSubsystem: a ready, tested lifecycle, without a single line of what I describe below. Your own base class earns its place when you need multiple instances (a subsystem is one instance per class per owner by definition), or when a designer is meant to create subclasses in Blueprint, which a subsystem cannot do.

Decision one: when you register

The default answer: in the constructor. Inheritance is enough. The base constructor runs on its own, the object lands in the registry, no extra code.

And that is exactly what you must not do. The constructor documentation says so outright:

If this is something like a UObject that could be created on a different thread (like for async loading), construct with a Never tick type and enable tick later.

— Tickable.h:147 (UE 5.7)

The base constructor in full:

// UE 5.7 — Tickable.cpp:133-145
FTickableGameObject::FTickableGameObject(ETickableTickType StartingTickType)
{
    if (StartingTickType != ETickableTickType::Never)
    {
        // It is only safe to create tickable game objects on the game thread, as otherwise there is a race condition between object initialize and the game thread tick
        // If you hit this ensure, change the constructor to use FTickableGameObject(ETickableTickType::Never) and call SetTickableTickType after initialization
        ensure(IsInGameThread());

        // Queue for creation, this can get called very early in startup
        FTickableStatics& Statics = GetStatics();
        Statics.QueueTickableObjectForAdd(this, StartingTickType);
    }
}

The base constructor runs before the body of the derived class constructor, before the archetype and Blueprint-class defaults are applied over the native ones, and before the owner has a chance to configure anything. Defaults are not applied until FObjectInitializer::PostConstructInit (UObjectGlobals.cpp:4239), the copy itself in UObjectGlobals.cpp:4350, and PostInitProperties runs later still (UObjectGlobals.cpp:4427) — all three after the C++ constructor chain. The next tick pass will call GetTickableTickType(), and then Tick(), on a half-configured object. On top of that, the CDO registers along with the instances, because the FTickableGameObject constructor does not check IsTemplate() or anything of the sort (Tickable.cpp:133-145).

The correct answer is to construct with an explicit “do not tick” and enable ticking later:

UTickableObject::UTickableObject()
    : FTickableGameObject(ETickableTickType::Never)
{
    // Deliberately empty. Registering for tick here is exactly what Tickable.h forbids.
}

Decision two: when you unregister

The default answer: in the destructor. And again it is too late. A UObject destructor runs long after the object stopped being useful, and in the meantime the engine is free to tick it.

The right place is an explicit method called by the owner, plus a hard gate in BeginDestroy() as the last line of defense. The tick queries themselves are gates too, each in its own place:

ETickableTickType UTickableObject::GetTickableTickType() const
{
    // Never for the CDO and before Initialize: the object stays out of the tickable
    // array entirely instead of sitting in it and being polled every frame.
    return (IsTemplate() || !bInitialized) ? ETickableTickType::Never : ETickableTickType::Conditional;
}

bool UTickableObject::IsTickable() const
{
    return bInitialized && bTickEnabled && CachedWorld.IsValid() && IsValidChecked(this);
}

The split between these two methods is deliberate. IsTemplate() belongs in GetTickableTickType, not in IsTickable: that way the CDO never enters the array at all, instead of sitting in it and answering “no” every frame. IsTickable is left for the conditions that genuinely change over the object’s lifetime.

// UE 5.7 — Tickable.cpp:59-63, indentation reduced (branch for an object not yet in the array)
else
{
    // Add to the pending list (which could override previous request), this will apply it next frame
    NewTickableObjects.Add(InTickable, NewTickType);
}

Decision three: which world you belong to

The default answer: none. Left unoverridden, GetTickableGameObjectWorld() returns nullptr (Tickable.h:187-190), and the object ticks in the global pass that follows all the worlds — knowing nothing about pause, nothing about PIE, nothing about the moment its world stops existing.

Overriding that method is cheap and handles all three at once:

UWorld* UTickableObject::GetTickableGameObjectWorld() const
{
    return CachedWorld.Get();
}

I resolve the world once, in Initialize(), and hold it in a TWeakObjectPtr<UWorld>. Plain GetWorld() is enough: the default UObject::GetWorld() implementation walks the Outer chain (Obj.cpp:1145-1150), so an object created with a sensible Outer finds its world with no help at all.

Here is the trap I ran into. Once the world is gone, CachedWorld.Get() starts returning nullptr. You would expect that to be the end of the tick. The opposite is true. The gate in the engine reads GetTickableGameObjectWorld() == World (Tickable.cpp:189), and TickObjects is also called with World == nullptr, precisely for objects with no world (GameEngine.cpp:1947). The comparison nullptr == nullptr passes. The object does not stop ticking. It quietly migrates from its own world’s tick to the global engine pass and keeps going.

The whole condition in the engine loop:

// UE 5.7 — Tickable.cpp:186-189 (indentation reduced)
// If it is tickable and in this world
if (TickableObject->IsAllowedToTick()
    && ((TickableEntry.TickType == ETickableTickType::Always) || TickableObject->IsTickable())
    && (TickableObject->GetTickableGameObjectWorld() == World))

Closing this takes two things at once: the CachedWorld.IsValid() condition in IsTickable(), and a subscription to world cleanup, so that the object shuts itself down instead of just no longer being polled.

void UTickableObject::HandleWorldCleanup(UWorld* World, bool bSessionEnded, bool bCleanupResources)
{
    if (World == CachedWorld.Get())
    {
        Shutdown();
    }
}

The delegate is FWorldDelegates::OnWorldCleanup, hooked up in Initialize() and removed in Shutdown(). Unregistering from inside your own broadcast is safe: Unreal’s multicast delegates defer compacting the list until the call finishes (MulticastDelegateBase.h:380-390).

Decision four: who cleans up

The default answer: nobody. A UObject with no UPROPERTY reference is collected at the next GC, and that is the correct behavior. It just has to be handled deliberately, instead of discovered halfway through a session when the object is already gone.

The reflex is AddToRoot(). That is not lifetime management; it is turning GC off for this object, with a manual RemoveFromRoot() as the only way out. The object survives a map change and everything else.

A sensible contract is simpler and puts both obligations on the owner: the object lives in a UPROPERTY(TObjectPtr<>), and Shutdown() runs before that reference is dropped.

So BeginDestroy() does exactly as much as it has to and not an ounce more: it removes the delegate (a plain Remove, no dispatch into Blueprint), kills the tick, and reports that the owner never called Shutdown().

void UTickableObject::BeginDestroy()
{
    FWorldDelegates::OnWorldCleanup.Remove(WorldCleanupHandle);
    WorldCleanupHandle.Reset();

    SetTickableTickType(ETickableTickType::Never);
    bTickEnabled = false;

    ensureAlwaysMsgf(!bInitialized,
        TEXT("%s: destroyed while still initialized - the owner never called Shutdown()."), *GetName());

    Super::BeginDestroy();
}

ensureAlwaysMsgf, not ensureMsgf: a plain ensure fires once per callsite per process. The bEnsureHasExecuted flag is keyed by a hash of __FILE__ and __LINE__, and the Always variant skips that filter (AssertionMacros.h:440-448). The first leaked object would silence the diagnostic for every one after it.

Epic does the same in UTickableWorldSubsystem::BeginDestroy (WorldSubsystem.cpp:154-159): it does not call Deinitialize from there — and now the reason is clear. Two differences from the listing above are deliberate: Epic leaves a plain ensureMsgf there (WorldSubsystem.cpp:158) and calls Super::BeginDestroy() first (WorldSubsystem.cpp:156).

The whole class

The complete implementation ships in StillCooking_Tools as USCTickableObject — a free, MIT-licensed plugin distributed as C++ source (GitHub), module StillCookingCore, header Objects/SCTickableObject.h. It is the class from this post, developed further: on top of the four decisions above it adds an explicit tick intent that Initialize() applies, the bTickWhenPaused and bTickInEditor gates, and a protected engine-facing interface with IsTickable() marked final.

• Reference: USCTickableObject — functions, properties, events and the messages it logs.
• Lifecycle — the ownership contract and what happens when the owner forgets Shutdown().

Checklist

Five things to check in your own class:

1. The constructor calls FTickableGameObject(ETickableTickType::Never) and does nothing else tick-related.
2. GetTickableTickType() returns Never for IsTemplate() and for the pre-initialization state, so the CDO never enters the array.
3. GetTickableGameObjectWorld() returns a real world, and IsTickable() checks whether that world is still alive.
4. There is an explicit shutdown method called by the owner, plus a world-cleanup subscription for the case where the world goes first.
5. BeginDestroy() kills the tick and reports the problem, but does not run subclass teardown.

A subsystem derives from one of five base classes. Each subsystem type is associated with a different owner and inherits that owner’s lifetime: UEngineSubsystem, UEditorSubsystem, UGameInstanceSubsystem, UWorldSubsystem (plus UTickableWorldSubsystem), or ULocalPlayerSubsystem (Runtime/Engine/Public/Subsystems/Subsystem.h:12-20). Everything below comes from reading the UE 5.8 source.

Choosing the base class is how you declare the subsystem’s lifetime. Everything else happens automatically.

All five follow the same contract: ShouldCreateSubsystem(UObject* Outer) → Initialize → Deinitialize. The first call is the exception. It runs on the CDO before an instance even exists, as the header states explicitly: “Note: This function is called on the CDO prior to instances being created!” (Subsystem.h:49-56).

Under the hood, the collection gathers every non-abstract derived class through GetDerivedClasses(BaseType, …, true) and asks each CDO whether that subsystem should be created (Private/Subsystems/SubsystemCollection.cpp:256,373-391). It stores the resulting instances in a TMap<UClass*, USubsystem*> (Public/Subsystems/SubsystemCollection.h:116-143). One instance per class per Outer isn’t a convention; it follows from the container type. The key is a concrete class, not a hierarchy. If another non-abstract class derives from that base class — a Blueprint child, for instance — its CDO gets asked the same question separately, and the collection ends up holding two independent instances. How this affects which class provides the implementation is covered separately in ShouldCreateSubsystem and the subsystem class hierarchy.

Where each collection starts

The first two rows are the easiest to get wrong. UEditorSubsystem and UEngineSubsystem derive from UDynamicSubsystem, which automatically populates the collection when a module loads and empties it when that module unloads. Your subsystem won’t exist until its module is explicitly loaded, and the engine won’t report an error if it isn’t.

The world startup timeline

By the time this timeline begins, the Engine and GameInstance collections have already been initialized. UEngine::Init runs during process startup, and UGameInstance::Init runs before the map load that creates the gameplay world.

The relevant points in the timeline are all in Runtime/Engine/Private/World.cpp:

1. UWorld::InitWorld() calls InitializeSubsystems (:2447) and, near the end, PostInitializeSubsystems (:2610). World subsystems receive both Initialize and PostInitialize.
2. UWorld::InitializeActorsForPlay() runs (:5946). Only then does the engine start handling actors placed in the level.
3. UWorld::BeginPlay() calls OnWorldBeginPlay on every World subsystem and then calls AGameModeBase::StartPlay() (:6165-6179).

The third point gives us a guarantee that no actor can provide: a World subsystem has been initialized and has already run OnWorldBeginPlay before GameMode starts gameplay. An actor placed in the level receives its BeginPlay during InitializeActorsForPlay/StartPlay, which puts it after the subsystems. That last part is my interpretation of the call order, not a guarantee stated on any single line of engine code, but it follows directly from that order.

An actor spawned during play is a different case. Its BeginPlay fires immediately after it is spawned, so the startup-order question doesn’t apply.

A manager actor comes close to providing the same guarantee, but only when three conditions are met: it derives from AInfo (or explicitly sets bIsSpatiallyLoaded = false), lives in the persistent level, and has no dependency on a streamed sublevel. The AInfo constructor sets bIsSpatiallyLoaded = false and bReplicates = false (Private/Info.cpp:11-45), which is exactly the kind of role Epic designed this class for.

A plain AActor placed in a World Partition level is spatially streamed by default and can be unloaded during gameplay. A subsystem is structurally immune to this class of bug because it doesn’t belong to any ULevel.

Where the ordering guarantee stops

The guarantee from the previous section applies only to this ordering. Everything below falls outside it, and that is where the assumption that “the subsystem is always there” breaks down.

There is no declarative ordering between collections. FSubsystemCollectionBase::InitializeDependency enforces ordering within a single collection and nowhere else. The header states this plainly: “Dependencies only work within a collection” (Public/Subsystems/SubsystemCollection.h:31-45). A World subsystem that accesses a GameInstance subsystem from inside Initialize has no declarative safeguard. You must either enforce the order yourself or defer that access until OnWorldBeginPlay, when the world has already been assembled.

A dynamic subsystem whose module hasn’t loaded never appears. A UEditorSubsystem placed in a module with the wrong LoadingPhase simply never reaches the collection (Subsystem.h:72-83, EditorSubsystem.h:9-23). The symptom is misleading: GetEditorSubsystem<T>() returns null even though the class compiles, loads, and looks perfectly fine in the editor.

A class that hasn’t been loaded never even makes the list. This is the same mechanism as the point above, seen from the other side. Non-dynamic collections run their GetDerivedClasses scan once, when the collection is created, and they only see the classes that are in memory at that moment. A Blueprint child of a subsystem with no hard references to that child isn’t loaded yet in a packaged build, so its CDO is never asked — and at the default log level a refusal and an absence look identical: both are just a missing line. The editor never shows the problem, because the Content Browser keeps the class in memory. I covered the whole case in A Blueprint subsystem does not get created in a packaged build.

A conditional ShouldCreateSubsystem eliminates the non-null guarantee. Epic does this in its own code: UInputDeviceSubsystem returns false on a dedicated server, in a commandlet, and when Slate hasn’t been initialized (Private/GameFramework/InputDeviceSubsystem.cpp:240-252). The consequence is visible in the subsystem’s own accessor. UInputDeviceSubsystem::Get() returns nullptr (:194-197), so every call within the engine is wrapped in an if, three times in ForceFeedbackEffect.cpp alone (:122, :190, :214).

Overriding this hook gives up the very property that often makes a subsystem appealing in the first place. From that point on, every GetSubsystem<T>() requires a null check, and the call site has no way to know whether it is running on a path where the subsystem was created. Sometimes that tradeoff is intentional. The condition in this method doubles as a way of declaring which class in the hierarchy should be the subsystem, and the null check becomes the price of moving the implementation one level down, into a Blueprint.

DoesSupportWorldType includes editor worlds by default. A gameplay manager that doesn’t override this method gets an instance in every world opened in the editor, not just in PIE. This happens because UWorldSubsystem overrides ShouldCreateSubsystem through DoesSupportWorldType, whose default implementation allows game, PIE, and editor worlds (Public/Subsystems/WorldSubsystem.h:33-66, especially :64-66). If the subsystem also derives from UTickableWorldSubsystem, it ticks from Initialize to Deinitialize for as long as the map remains open in the editor (WorldSubsystem.h:72-106).

Confirming this in your own project

You can verify the entire timeline above in a single editor run. Log four points and include the world type on every line:

void UMyWorldSubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    Super::Initialize(Collection);
    UE_LOG(LogMyGame, Log, TEXT("[1] Subsystem::Initialize | World=%s Type=%d"),
        *GetWorld()->GetName(), (int32)GetWorld()->WorldType);
}

void UMyWorldSubsystem::OnWorldBeginPlay(UWorld& InWorld)
{
    Super::OnWorldBeginPlay(InWorld);
    UE_LOG(LogMyGame, Log, TEXT("[2] Subsystem::OnWorldBeginPlay"));
}

// AMyManagerActor::BeginPlay  → [3]
// AMyGameMode::StartPlay      → [4]

Seeing 1 → 2 → 3 → 4 in the log confirms the guarantee for one specific project and one specific streaming setup. If [3] appears before [2], the actor is being spawned rather than placed in the level. Its BeginPlay fires immediately after the spawn and has nothing to do with the world startup timeline.

The ordering guarantee is real, and the engine code enforces it, but it covers exactly one thing: a World subsystem exists before actors in that same world receive BeginPlay. It extends no further than that single axis. Everything above also covers startup only; the order in which a world and a session shut down is a separate question, and this note leaves it open.

The game code has to answer every other question for itself, and the engine won’t even signal that the question came up.

There are two ways to call an interface function in Unreal: cast to the I* type or use the generated Execute_ wrapper. They look interchangeable, but they ask the engine two different questions.

Cast<IMyInterface>(Obj) returns nullptr for an object whose interface implementation exists only in Blueprint. For that same object, Obj->GetClass()->ImplementsInterface(UMyInterface::StaticClass()) returns true. The engine deliberately skips interface entries added by the Blueprint compiler, so casting to I* is safe only when the interface is explicitly marked as non-implementable in Blueprint. Everywhere else, it is a silent bug waiting for the day a designer creates a Blueprint implementation.

The whole problem comes down to one specific configuration: a native interface declared in C++ and implemented in Blueprint.

Two functions, one condition apart

GetInterfaceAddress and ImplementsInterface both walk the same UClass::Interfaces array and test the same relationship with IsChildOf. Exactly one extra condition separates them.

UObjectBaseUtility::GetInterfaceAddress (Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBaseUtility.cpp), in the branch for a native interface:

for (TArray<FImplementedInterface>::TIterator It(CurrentClass->Interfaces); It; ++It)
{
    // See if this is the implementation we are looking for, and it was done natively, not in K2
    FImplementedInterface& ImplInterface = *It;
    if ( !ImplInterface.bImplementedByK2 && ImplInterface.Class->IsChildOf(InterfaceClass) )
    {
        Result = (uint8*)this + It->PointerOffset;
        break;
    }
}

UClass::ImplementsInterface (Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp), with the same loop:

for (TArray<FImplementedInterface>::TConstIterator It(CurrentClass->Interfaces); It; ++It)
{
    const UClass* InterfaceClass = It->Class;
    if (InterfaceClass && InterfaceClass->IsChildOf(SomeInterface))
    {
        return true;
    }
}

The entire difference is !ImplInterface.bImplementedByK2. That flag marks an entry produced by the Blueprint compiler, and the engine’s own comment says exactly that: “and it was done natively, not in K2.” ImplementsInterface has no such filter, so it gives the broader answer: the class implements the interface. GetInterfaceAddress gives a narrower answer: the class implements the interface natively.

And GetInterfaceAddress is the cast. Not figuratively but literally, in Engine/Source/Runtime/CoreUObject/Public/Templates/Casts.h:

if constexpr (TIsIInterface<To>::Value)
{
    return (To*)((UObject*)Src)->GetInterfaceAddress(To::UClassType::StaticClass());
}

A cast to an interface never touches the class-cast-flag path used by a plain Cast<AActor>. Instead, it calls a function designed specifically to exclude Blueprint implementations.

Why there is nothing to return

This looks like an oversight. It is a constraint of the memory layout.

A C++ class that implements IMyInterface inherits from it, so its memory layout contains an IMyInterface subobject at a known offset. That offset is exactly what the cast is built on: (uint8*)this + It->PointerOffset. If the interface is implemented only in Blueprint, there is no corresponding native IMyInterface subobject, so there is nothing for PointerOffset to describe. Without that subobject, there is no IMyInterface vtable either, and therefore no address for the cast to return.

A Blueprint implementation exists in a completely different form. It is a UFunction on the Blueprint class, invoked through the virtual machine. No valid pointer exists, so nullptr is the only honest answer.

Cast itself is what makes this misleading: it looks like a uniform reflection mechanism, but in this case it is really asking about native memory layout.

The fix: Execute_

For every interface function, UHT generates a static Execute_Foo wrapper. AppendInterfaceCallFunction (Engine/Source/Programs/Shared/EpicGames.UHT/Exporters/CodeGen/UhtHeaderCodeGeneratorCppFile.cs) emits the body, which expands to this:

static FName NAME_UMyInterface_Foo = FName(TEXT("Foo"));
void IMyInterface::Execute_Foo(UObject* O)
{
    check(O != NULL);
    check(O->GetClass()->ImplementsInterface(UMyInterface::StaticClass()));
    UFunction* const Func = O->FindFunction(NAME_UMyInterface_Foo);
    if (Func)
    {
        O->ProcessEvent(Func, NULL);
    }
    else if (auto I = (IMyInterface*)(O->GetNativeInterfaceAddress(UMyInterface::StaticClass())))
    {
        I->Foo_Implementation();
    }
}

The order is the opposite of what you would expect. FindFunction comes first. That is the reflection path, and it finds a Blueprint override just as well as a UHT-registered native function. Only when there is no UFunction does the wrapper retrieve the native subobject address and call _Implementation directly.

Execute_ gates itself on ImplementsInterface, the broader check, not on the existence of an interface address.

The correct call site therefore looks like this:

if (Obj->Implements<UMyInterface>())
{
    IMyInterface::Execute_Foo(Obj);
}

A second safeguard sits in the native body of the event function itself. For interfaces, UHT emits that body as a hard assertion:

check(0 && "Do not directly call Event functions in Interfaces. Call Execute_Foo instead.");

That gives Cast<IMyInterface>(Obj)->Foo() two independent ways to fail. Either the cast returns nullptr and the program crashes on the dereference, or the cast succeeds and the call runs straight into the assertion. The nullptr failure is worse because it occurs only for objects whose interface implementation comes from Blueprint.

When the cast is valid

A cast to I* covers every implementation of the interface under exactly one condition: the interface must be explicitly non-implementable in Blueprint. Then bImplementedByK2 is never set on any entry, so GetInterfaceAddress and ImplementsInterface always agree.

UINTERFACE(BlueprintType, meta=(CannotImplementInterfaceInBlueprint), MinimalAPI)
class UDamageSource : public UInterface { GENERATED_BODY() };

Verification

I verified this in the editor, not just by reading the source. The probe collects three readings for the same object: ImplementsInterface, a cast to the interface type, and GetNativeInterfaceAddress. It then calls Execute_. The test interface allows Blueprint implementations, so the test can cover the case where the cast fails:

UINTERFACE(Blueprintable)
class UPickupTarget : public UInterface { GENERATED_BODY() };

class IPickupTarget
{
    GENERATED_BODY()
public:
    UFUNCTION(BlueprintNativeEvent, Category = "Probe")
    void OnPicked();
};

// Control group: native implementation.
UCLASS()
class ANativePickup : public AActor, public IPickupTarget
{
    GENERATED_BODY()
public:
    virtual void OnPicked_Implementation() override
    {
        UE_LOG(LogTemp, Warning, TEXT("[probe] OnPicked from C++"));
    }
};

UCLASS()
class UInterfaceProbe : public UBlueprintFunctionLibrary
{
    GENERATED_BODY()
public:
    UFUNCTION(BlueprintCallable, Category = "Probe")
    static void Probe(UObject* Obj);
};

void UInterfaceProbe::Probe(UObject* Obj)
{
    if (!Obj)
    {
        return;
    }

    const bool bImplements = Obj->GetClass()->ImplementsInterface(UPickupTarget::StaticClass());
    IPickupTarget* AsInterface = Cast<IPickupTarget>(Obj);
    void* NativeActor = Obj->GetNativeInterfaceAddress(UPickupTarget::StaticClass());

    UE_LOG(LogTemp, Warning, TEXT("[probe] %s | Implements=%s | Cast=%s | NativeActor=%s"),
        *Obj->GetClass()->GetName(),
        bImplements ? TEXT("true") : TEXT("false"),
        AsInterface ? TEXT("ptr") : TEXT("NULL"),
        NativeActor ? TEXT("ptr") : TEXT("NULL"));

    if (bImplements)
    {
        IPickupTarget::Execute_OnPicked(Obj);
    }
}

The second implementation of the same interface is created in the editor: a Blueprint Actor class named BP_BlueprintPickup, with the Pickup Target interface added under Class Settings and an On Picked event that prints [probe] OnPicked from BP.

The Level Blueprint of an empty map drives the test. NativePickup is spawned in BeginPlay. BP_BlueprintPickup is placed in the level and retrieved with Get Actor of Class. Both objects pass through the same Probe along a single execution chain:

The log from that run:

LogTemp: Warning: [probe] NativePickup | Implements=true | Cast=ptr | NativeActor=ptr
LogTemp: Warning: [probe] OnPicked from C++
LogTemp: Warning: [probe] BP_BlueprintPickup_C | Implements=true | Cast=NULL | NativeActor=NULL
LogBlueprintUserMessages: [probe] OnPicked from BP

In the third line, Implements=true sits next to Cast=NULL for the same object in the same call. The fourth line shows Execute_ invoking the implementation despite the NULL. The LogBlueprintUserMessages category confirms that the call landed in the Blueprint graph rather than the native fallback.

The first two lines are the control group. For a native implementation, all three readings agree and the cast works. The comparison focuses on where the interface implementation comes from.

Limits

An interface class declared in Blueprint rather than in C++ — that is, one without CLASS_Native — behaves differently. For such an interface, GetInterfaceAddress never enters the loop over Interfaces. It returns this, provided ImplementsInterface is true. That is a separate branch of the same function in Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBaseUtility.cpp.

This also has consequences for testing. A test built entirely from C++ classes will never catch the problem. Every implementation is native, bImplementedByK2 is false everywhere, and the cast works every time. You can see that in the first two lines of the log above, where the control group passes. A test must include a Blueprint that implements the interface; otherwise, it exercises only the variant that was already correct.

As for the limits of the evidence: the mechanism comes from reading the UE 5.7 source (UObjectBaseUtility.cpp, Class.cpp, Casts.h, and the UHT generator) and was confirmed by one run in the editor on the same version. I have not checked whether PointerOffset and the bImplementedByK2 filter behave the same way in older engine branches.

Sources

• UObjectBaseUtility::GetInterfaceAddress, GetNativeInterfaceAddress — Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBaseUtility.cpp
• UClass::ImplementsInterface — Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp
• Cast / CastChecked for interfaces — Engine/Source/Runtime/CoreUObject/Public/Templates/Casts.h
• Execute_ generation — Engine/Source/Programs/Shared/EpicGames.UHT/Exporters/CodeGen/UhtHeaderCodeGeneratorCppFile.cs, AppendInterfaceCallFunction
• Unreal Docs: Interfaces — the official description of UINTERFACE and Execute_ calls

It is deliberately not a framework: every entry stands on its own, so you can take one class or one Blueprint node and ignore the rest. Nothing here depends on anything outside the engine. Inside: USCTickableObject, a UObject that ticks every frame without being an Actor or a Component; a console command registry whose commands have Blueprint bodies; four Flow nodes — For Each Index With Delay, For Each Index Per Tick, Do For Duration and Wait Until; and Print String Formatted, a Print String whose {Placeholders} become pins. The C++ cores under the Flow nodes are usable directly.

Limits worth knowing up front

• A C++ project is required. The plugin is distributed as source and compiled together with your project, so a Blueprint-only project will not build it.
• Two entries are development-only. The console command registry compiles its registration out of Shipping, and Print String Formatted is compiled out of Shipping and Test builds.
• The C++ layer under the Flow nodes is EXPERIMENTAL. The Blueprint nodes are stable; the FSCFlow* classes under them may change shape without a major version bump.
• Nothing replicates. No entry knows about the network.
• Game Thread only. Nothing in the plugin is thread-safe; calls from other threads are unsupported.

The whole list: Limits.

The plugin is free, distributed as C++ source on GitHub under the MIT license.