Do parties in a Lightning Network channel need to be online? I'm thinking of a scenario where users on mobile devices using a LN client will rarely be online.

Let's say Alice opens a channel with Bob and they make 10 LN transactions. After Alice has received the 10th, she goes offline for longer than the channel's lifetime.

So if the channel was setup to last for 3 days, she'll be offline for say, 5 days.

My question is, when Alice comes back online, how does she know whether Bob commited to the blockchain the 10th and not an earlier transaction (which is in favor of Bob).

I understand that if Alice was online she could check this behavior herself, and readily commit the 10th to get her money. But the key point here is that she's offline longer than the channel's lifetime.

Is there a solution to this in LN? Because frankly, most users will not have a node that is online 24/7. And also, I don't want to trust a third-party to commit the 10th transaction at the right time -- what if they don't? Who's to say they will also act honestly and not commit an earlier transaction from the channel?
The lightning network is comprised of bi-directional payment channels between two nodes.  This means that either one of those nodes should be able to initialize a transaction at any time.  These transactions require both parties to be actively participating in updating the smart contracts that keep the channel alive.  If one party fails to respond, they are essentially in violation of the smart contract, and are forfeiting their claim to any of the funds in the channel.

Non-responsive clients are a liability to anyone opening up a channel.  It means that their bitcoin may be tied up in the channel until the timeout period.  That bitcoin was typically put there either to make a payment (which now is delayed), or to earn network fees for being a hub of other people's transactions.  An unresponsive node means the channel is wasted.  It's similar to a denial of service attack, except it's tying up bitcoin rather than bandwidth.

To illustrate how this works, consider that Alice and Bob have each contributed 1BTC to a shared channel.  The entire channel now has a total of 2BTC in it, but it has a cap in each direction.  Because Alice only put in 1BTC, the most that will ever flow from Alice to Bob is 1BTC.  This is the same for total transactions from Bob to Alice.

Let's say that more money has flowed from Alice to Bob during the lifetime of the channel, so that if it were closed right now, Alice would get 0.5BTC, and Bob would get 1.5BTC (excluding fees for simplicity).  Now let's say Bob all of a sudden went offline, leaving the channel useless.

Due to how the smart contracts work, Alice will have a valid bitcoin transaction from earlier, that was signed by Bob, and could close the channel leaving Alice with more than the 0.5BTC she is owed.  Alice can broadcast this transaction to the Bitcoin network, and after a timeout period, will get Bob's rightful money.  The only thing that prevents this, is that Bob will see the transaction propagate on the network, and can submit the final transaction that he has (already signed by Alice) to get his full payment before Alice's transaction is valid.  If Bob isn't paying attention, then Alice can steal what is rightfully his.

Penalizing unresponsive nodes is a feature of the lightning network, intended to keep it functional.  By leaving the channel unattended, Bob is doing Alice a disservice.  Making that behavior financially disastrous is what makes the system work in the first place.