A session token of any kind, JWT included, is expected to be an opaque blob to the client. This is actually enforced for most tokens stored in cookies, where the HttpOnly flag means the client can't inspect the cookie. Even for bearer tokens, though, there's no need to inspect the token client-side.
Indeed, I'd be suspicious of any system where any element of its security depended on the client validating the session token. Client-side validation can be useful for convenience or for offloading some performance (for example, the client might notice a token is about to expire and refresh it), but the server always must perform its own validation and make no expectation of the validity of the client data (in that example, the server needs to operate correctly if the client doesn't refresh in time, refreshes constantly, sends an invalid refresh token, etc.).
I'm not entirely sure what you mean by "accessing cached data within the screens", but it doesn't sound like a relevant problem at all. If the app wants to know how long sessions last (so it can clear its cache when they end), that's a reasonable thing to desire, but there's no need or reason for it to verify the token for this purpose; if the attacker can modify the token they can (almost certainly) also just access the cache directly.
Assuming the token is only ever transmitted over secure connections and not stored when an untrusted user/app can access it (which... if either aren't true you have other, very large problems, but none due to the risk of the token being invalid), and that the token isn't being used as anything other than "a token" (i.e. it's not also an key for client-side data encryption or some such), there's really no need for the client to know anything about the token at all.
The reason people use asymmetric signatures in JWTs is so that only one service can mint them, but others - which the minter might not trust - can verify them. The client/bearer is not generally a "service" in this sense. The reason people use keyed hashes in JWTs is because asymmetric crypto is very computationally expensive, especially if you want the same degree of security. The ability for the client to make heads or tails of the signature is never, in my experience, relevant (even with asymmetric signatures I've never seen a case like you talk about, where the service actually publishes the public key to the client; it's just not relevant).