If the app does not run at all times, there is a risk of a channel being unilaterally closed due to HTLC expiration. Users will also have to decide how many channels should be opened and what the fee per channel should be. Additionally, they need to know how much funds can be relayed at max without interfering with their payments. However, most users prefer not to be asked these kinds of questions as they just want an app to do its job and get out of their way.Combining multiple channels is trivial, but there seems to be an asymmetry: payees can generate multiple routes, while payers, once receiving a single route, cannot pay if no channel's capacity is sufficient. The underlying connections do not actually have to show up in the UX interface at all, but this can lead to problems such as a user refilling their account with 9 SAT and then finding out they cannot pay for a 10 SAT transaction.One solution to this problem is to make sure users understand that a balance is multidimensional. Another solution is to bilaterally close existing channels before creating new ones and recombine their balances, which is no better than a single channel re-anchoring. While having a single channel may not solve all the issues, it makes them obvious to the user. Developers can choose whether to use a single or multiple channels based on their preferences and the needs of their users.